AlexanderSehr
commented
1 year ago Put on hold as it's a special beast and we may or may not want to publish it as is in the first place. The main value comes through it's child modules and those are not published in AVM.
To do
Checklist
1. Tests ([ref](https://azure.github.io/Azure-Verified-Modules/specs/bicep/#id-bcpnfr9---category-testing---expected-test-directories)) - [ ] Rename test folder and add nested `e2e` folder ([ref](https://azure.github.io/Azure-Verified-Modules/contributing/bicep/#example-directory-and-file-structure-within-azurebicep-registry-modules-repository)) - [ ] Rename `min` folder to `defaults` - [ ] Rename `common` folder to `max` - [ ] Add `waf-aligned` folder (e.g., based on `common`). This test should not fail PSRule & show the module being deployed with best-practices - [ ] For each folder, - [ ] Update the `serviceShort` parameter to align with the new naming (e.g., `waf` for `waf-aligned`). For now, we should continue using `min` for `defaults` to align with PSRule. - [ ] Update the `namePrefix` input parameter value from `[[namePrefix]]` to `#_namePrefix_#` (the reason being that Bicep has a compilation issue because of the prefix & suffix in another location) - [ ] Remove the `enableDefaultTelemetry` parameter and reference in the test - [ ] Update the `../../main.bicep` module template reference to `../../../main.bicep` - [ ] If a resource group is deployed, update the RG parameter name to the new format that also uses the `namePrefix`. For example: ```bicep @description('Optional. The name of the resource group to deploy for testing purposes.') @maxLength(90) param resourceGroupName string = 'dep-${namePrefix}-network.privateendpoints-${serviceShort}-rg' ``` - [ ] (Optionally) add a block like the following below the target scope to render a more meaningful example in the ReadMe ```Bicep metadata name = 'Using only defaults' metadata description = 'This instance deploys the module with the minimum set of required parameters.' ``` - [ ] You should also try and test idempotency if possible. You can do this by updating the test invocation to ```bicep @batchSize(1) module testDeployment '../../../main.bicep' = [for iteration in [ 'init', 'idem' ]: { scope: resourceGroup name: '${uniqueString(deployment().name, location)}-test-${serviceShort}-${iteration}' (...) }] ``` 1. For each module that supportsDiagnostic Settings
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#diagnostic-settings) - [ ] Add the `diagnosticSettingType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Remove any of the current diagnosticSetting parameters & variables - [ ] Add the the new `diagnosticSettings` parameter as per the specs to the template - [ ] Updated the deployment block as per the specs to enable it to work with the new object type - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep diagnosticSettings: [ { name: 'customSetting' eventHubName: diagnosticDependencies.outputs.eventHubNamespaceEventHubName eventHubAuthorizationRuleResourceId: diagnosticDependencies.outputs.eventHubAuthorizationRuleId storageAccountResourceId: diagnosticDependencies.outputs.storageAccountResourceId workspaceResourceId: diagnosticDependencies.outputs.logAnalyticsWorkspaceResourceId } ] ``` > **NOTE:** ⚠️ Make sure that if the module does not support e.g. metrics, that you update the logic accordinglyRole Assignments
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#role-assignments) - [ ] Add the `roleAssignmentType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Update the current `roleAssignments` parameter as per the specs (- should now reference the User-defined-type) - [ ] Take the current list of `builtInRoleNames` from the `nested_roleAssignments.bicep` file and add them to the variables block of the main template. The new schema does not require the nested template. Also, reduce the list of specified roles to only those that make sense for this resource ([ref](https://azure.github.io/Azure-Verified-Modules/specs/bicep/#id-bcpnfr5---category-composition---role-assignments-role-definition-mapping-limits))/ For, for example, Cognitive Services, we should only provide the important ones as Owner, Contributor, etc. + all service specific roles such as 'Cognitive Services User'. - [ ] Replace the original module deployment block with the new resource deployment block - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep roleAssignments: [ { roleDefinitionIdOrName: 'Reader' principalId: nestedDependencies.outputs.managedIdentityPrincipalId principalType: 'ServicePrincipal' } ] ```Resource Locks
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#resource-locks) - [ ] Add the `lockType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Update the current `lock` parameter as per the specs (- should now reference the User-defined-type) - [ ] Updated the deployment block as per the specs to enable it to work with the new object type - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep lock: { kind: 'CanNotDelete' name: 'myCustomLockName' } ```Tags
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#tags) - [ ] Update the current `tags` parameter as per the specsManaged Identities
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#managed-identities) - [ ] Add the `managedIdentitiesType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Remove any of the current identity parameters & variables - [ ] Add the the new `managedIdentities` parameter as per the specs to the template - [ ] Updated the deployment block as per the specs to enable it to work with the new object type - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep managedIdentities: { systemAssigned: true userAssignedResourcesIds: [ nestedDependencies.outputs.managedIdentityResourceId ] } ``` > **NOTE:** ⚠️ Make sure that if the module does not support e.g. user-assigned-identities, that you update the logic accordinglyPrivate Endpoints
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#private-endpoints) - [ ] Add the `privateEndpointType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Update the current `privateEndpoints` parameter as per the specs (- should now reference the User-defined-type) - [ ] Updated the deployment block as per the specs to enable it to work with the new object type. > Note: For any resource that only supports one service/groupID (e.g. `'vault'` for KeyVault, but NOT `'blob'` for StorageAccount) we can provide a default value for that property (hence there are 2 variants in the spec). - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep privateEndpoints: [ { privateDnsZoneResourceIds: [ nestedDependencies.outputs.privateDNSZoneResourceId ] subnetResourceId: nestedDependencies.outputs.subnetResourceId tags: { 'hidden-title': 'This is visible in the resource name' Environment: 'Non-Prod' Role: 'DeploymentValidation' } } ] ```Customer Managed Keys
> Reference to [AVM specs](https://azure.github.io/Azure-Verified-Modules/specs/shared/interfaces/#customer-managed-keys) - [ ] Add the `customerManagedKeyType` described in the above reference to a `// Definitions` block at the bottom of the template file - [ ] Remove any of the current customer-managed-key parameters & variables - [ ] Add the the new `customerManagedKey` parameter as per the specs to the template - [ ] Update the `existing` resource references as per the specs - [ ] Updated the deployment block as per the specs to enable it to work with the new object type - ⚠️ BEWARE module-specific differences - Note also that the new schema SHOULD support system-assigned-identities. As this cannot be done in a single deployment, you can find a reference how this would look like [here](https://github.com/eriqua/bicep-registry-modules/blob/main/avm/res/cognitive-services/account/tests/e2e/system-assigned-cmk-encryption/main.test.bicep) - [ ] Check if any of the tests must be updated. The new block may look like ```Bicep customerManagedKey: { keyName: nestedDependencies.outputs.keyVaultKeyName keyVaultResourceId: nestedDependencies.outputs.keyVaultResourceId userAssignedIdentityResourceId: nestedDependencies.outputs.managedIdentityResourceId } ``` > **NOTE:** ⚠️ Make sure that if the module does not support e.g. metrics, that you update the logic accordingly