Azure / bicep-types-az

Bicep type definitions for ARM resources
MIT License
84 stars 27 forks source link

Idempotency and circular and self references Microsoft.Cache/redisEnterprise/databases with geoReplication #1710

Open herman1vdb opened 1 year ago

herman1vdb commented 1 year ago

Bicep version 3.224.0

When deploying an Active-Active deployment of RedisEnterprise with bicep one is required to define the linkedDatabases.

When you deploy the first instance in weu, the linked databases is (problem 1) itself. solved by doing this: (resourceId also don't seem to work) '${subscription().id}/resourceGroups/${weuRg.name}/providers/Microsoft.Cache/redisEnterprise/${weuRedisEnterprise.name}/databases/default'

When you deploy the neu instance you have to link it self and the we database which can be referenced as seen above and weuRedisDatabase.id.

next time round with running my pipeline it would then of course fail with:

Linked databases cannot by removed with this API. In order to unlink a database, it must be deleted or removed with the 'forceUnlink' action. Since the weu databaser has been linked with the neu database in the meantime with the neu deployment

Using Microsoft.Cache/redisEnterprise/databases@2022-01-01

stephaniezyen commented 1 year ago

Can you provide a more complete bicep sample so we can repro on our end?

herman1vdb commented 1 year ago

Hi, Below is an approximation of the bicep that produces the problems described:

module weuRedisDatabase 'redis-databases.bicep' = {
  name: 'weuRedisDatabase-${deploymentId}'
  scope: weuRg
  params: {
    name: weuRedisEnterpriseName
    location: weuRg.location
    linkedDatabaseIds:['${subscription().id}/resourceGroups/${weuRg.name}/providers/Microsoft.Cache/redisEnterprise/${weuRedisEnterpriseName}/databases/default']
  }
}

module neuRedisDatabase 'redis-databases.bicep' = {
  name: 'neuRedisDatabase-${deploymentId}'
  scope: neuRg
  params: {
    name: neuRedisEnterpriseName
    location: neuRg.location
    linkedDatabaseIds:['${subscription().id}/resourceGroups/${neuRg.name}/providers/Microsoft.Cache/redisEnterprise/${neuRedisEnterpriseName}/databases/default', weuRedisDatabase.outputs.redisDatabaseId]
  }
}
//     ---  redis-databases.bicep  ---

param name string
param linkedDatabaseIds array = []
param location string = resourceGroup().location

resource redisEnterprise 'Microsoft.Cache/redisEnterprise@2022-01-01' = {
  name: name
  location: location
  sku: {
    capacity: 2
    name: 'Enterprise_E10'
  }
  properties: {
  }
  zones: [
    '1'
    '2'
    '3'
  ]
}

resource redisDatabase 'Microsoft.Cache/redisEnterprise/databases@2022-01-01' = {
  name: 'default'
  parent: redisEnterprise
  properties: {
    clientProtocol: 'Plaintext'
    clusteringPolicy: 'EnterpriseCluster'
    evictionPolicy: 'NoEviction'
    geoReplication: {
      groupNickname: 'my-redis-replication'
      linkedDatabases:[for linkedDatabaseId in linkedDatabaseIds: { id: linkedDatabaseId }]
    }
    modules: [
      {
        name: 'RedisJSON'
      }
      {
        name: 'RediSearch'
      }
    ]
    persistence: {
      aofEnabled: false
      rdbEnabled: false
    }
    port: 10000
  }
}

output redisDatabaseId string = redisDatabase.id
Bluhman commented 1 year ago

At least from my experience the issue specifically occurs when attempting to deploy a redis enterprise database cluster with both Geo-Replication and Modules enabled. If you deploy without the modules attached, then it works fine, which would be great if it was possible to change active modules after the resource is deployed.

Please let us know what the intended pattern is to enable both these features as it's blocking our ability to deploy our resources and successfully leverage Redis OM, thanks.

herman1vdb commented 1 year ago

Hi @stephaniezyen

Have you looked at the sample I provided? This issue seem to be related too: https://github.com/Azure/bicep-types-az/issues/1458