[BUG] Unable to set mutable properties on CosmosDB/Redis when modeled as existing resources

[captainsafia]

Library name and version

Azure.Provisioning v1.0.0

Describe the bug

While working on adding existing resource support to Aspire, I realized that there's spooky behavior in the provisioning APIs that appears to mark certain properties as read-only properties by overloading the IsOutput value. This makes it difficult to set certain configuration options, like Redis's IsAccessKeyAuthenticationDisabled property. This requires that we implement workarounds like the following to support mutating these:

    /// <remarks>
    /// The provisioning APIs will mark the IsAccessKeyAuthenticationDisabled as `ReadOnly` after the
    /// `IsExistingResource` property is set, making it impossible to configure the
    /// `IsAccessKeyAuthenticationDisabled` property in our usual flows. This is a workaround to
    /// allow us to set the property on existing resources.
    /// </remarks>
    private sealed class ExistingCdkRedisResource : CdkRedisResource
    {
        public ExistingCdkRedisResource(string bicepIdentifier, bool isAccessKeyAuthenticationDisabled, string? resourceVersion = null) : base(bicepIdentifier, resourceVersion)
        {
            IsAccessKeyAuthenticationDisabled = isAccessKeyAuthenticationDisabled;
            IsExistingResource = true;
        }
    }

There's a case to be made about these properties being immutable for existing resources but the overloading of output/read-only feels awkward here.

Expected behavior

Properties are not erroneously marked as output properties for existing resources.

Actual behavior

Exceptions thrown when setting certain properties as follows:

var resource = RedisResource.FromExisting("name");
resource.IsAccessKeyAuthenticationDisabled = false; // Invalid

Reproduction Steps

var resource = RedisResource.FromExisting("name");
resource.IsAccessKeyAuthenticationDisabled = false; // Invalid

Environment

No response

[jsquire]

//cc: @m-nash, @ArthurMa1978

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[eerhardt]

Related to [BUG] Storage account validation is too aggressive on existing accounts (Azure/azure-sdk-for-net#47489).

I'm no expert here, but I think in order to change properties on an existing resource, you have to do this double bicep thing:

param storageAccountName string

resource existingStorageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' existing = {
  name: storageAccountName
}

resource storageAccountUpdate 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: existingStorageAccount.name
  location: location
  properties: {
    networkAcls: {
      ipRules: map(web.properties.outboundIpAddresses, ip => { value: ip, action: 'Allow' }) 
      virtualNetworkRules: []
      bypass: 'AzureServices'
      defaultAction: 'Deny'
    }
  }
}

The first resource ensures that a storage account with the name matching the storageAccountName param exists. Then the second resource modifies the properties on that existing storage account (although note that it doesn't have an existing tag in the resource declaration.

If you don't do it this way, you get a bicep error:

ERROR: C:\Users\eerhardt\AppData\Local\Temp\aspireujbazmjb.lfu\cosmos.module.bicep(8,3) : Error BCP173: The property "properties" cannot be used in an existing resource declaration. [https://aka.ms/bicep/core-diagnostics#BCP173]