Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AVM Module Issue]: Improve setup of database account properties #3910

Open
1 task done
dmusic opened this issue Dec 10, 2024 · 4 comments
Open
1 task done

[AVM Module Issue]: Improve setup of database account properties #3910

dmusic opened this issue Dec 10, 2024 · 4 comments
Assignees
Labels
Class: Resource Module 📦 This is a resource module Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue Type: Feature Request ➕ New feature or request

Comments

@dmusic
Copy link

dmusic commented Dec 10, 2024

Check for previous/existing GitHub issues

  • I have checked for previous/existing GitHub issues

Issue Type?

Feature Request

Module Name

avm/res/document-db/database-account

(Optional) Module Version

0.10.0

Description

Currently, there are multiple issues raised due to the fact that always at least one "dummy" database needs to be set to be able to set correctly database account properties.

The problematic code is here:

var databaseAccountProperties = union(
  {
    databaseAccountOfferType: databaseAccountOfferType
    backupPolicy: backupPolicy
    capabilities: capabilities
    minimalTlsVersion: minimumTlsVersion
    capacity: {
      totalThrougputLimit: totalThroughputLimit
    }
  },
  ((!empty(sqlDatabases) || !empty(mongodbDatabases) || !empty(gremlinDatabases) || !empty(tables))
    ? {
        // NoSQL, MongoDB RU, Table, and Apache Gremlin common properties
        consistencyPolicy: consistencyPolicy[defaultConsistencyLevel]
        enableMultipleWriteLocations: enableMultipleWriteLocations
        locations: empty(databaseAccount_locations) ? defaultFailoverLocation : databaseAccount_locations

        ipRules: ipRules
        virtualNetworkRules: virtualNetworkRules
        networkAclBypass: networkRestrictions.?networkAclBypass ?? 'None'
        publicNetworkAccess: networkRestrictions.?publicNetworkAccess ?? 'Disabled'
        isVirtualNetworkFilterEnabled: !empty(ipRules) || !empty(virtualNetworkRules)

        enableFreeTier: enableFreeTier
        enableAutomaticFailover: automaticFailover
        enableAnalyticalStorage: enableAnalyticalStorage
      }
    : {}),
  ((!empty(sqlDatabases) || !empty(tables))
    ? {
        // NoSQL and Table properties
        disableLocalAuth: disableLocalAuth
        disableKeyBasedMetadataWriteAccess: disableKeyBasedMetadataWriteAccess
      }
    : {}),
  (!empty(mongodbDatabases)
    ? {
        // MongoDB RU properties
        apiProperties: {
          serverVersion: serverVersion
        }
      }
    : {})
)

I see an issue using databases properties here as for initial provisioning users usually do not need to have database/collection and will set them up later and with separate provisioning.

I would recommend following:

  1. Introduce new parameter "apiType/serviceType":
@description('Optional. API type for CosmosDB account.')
@allowed([
  'NoSQL'
  'MongoDB' 
  'Table'
  'Gremlin'
  //'Cassandra' // currently not supported in AVMs
])
param apiType string = 'NoSQL'
  1. Use this parameter in setup of databaseAccountProperties:
var databaseAccountProperties = union(
  {
    databaseAccountOfferType: databaseAccountOfferType
    backupPolicy: backupPolicy
    capabilities: capabilities
    minimalTlsVersion: minimumTlsVersion
    capacity: {
      totalThroug**h**putLimit: totalThroughputLimit
    }
    consistencyPolicy: consistencyPolicy[defaultConsistencyLevel]
    enableMultipleWriteLocations: enableMultipleWriteLocations
    locations: empty(databaseAccount_locations) ? defaultFailoverLocation : databaseAccount_locations

    ipRules: ipRules
    virtualNetworkRules: virtualNetworkRules
    networkAclBypass: networkRestrictions.?networkAclBypass ?? 'None'
    publicNetworkAccess: networkRestrictions.?publicNetworkAccess ?? 'Disabled'
    isVirtualNetworkFilterEnabled: !empty(ipRules) || !empty(virtualNetworkRules)

    enableFreeTier: enableFreeTier
    enableAutomaticFailover: automaticFailover
    enableAnalyticalStorage: enableAnalyticalStorage
    
    disableKeyBasedMetadataWriteAccess: disableKeyBasedMetadataWriteAccess
  },
  (apiType == 'SQL') // disableLocalAuth is only releveant for NoSQL, disableKeyBasedMetadataWriteAccess is relevant for all api types
    ? {
        // NoSQL properties
        disableLocalAuth: disableLocalAuth
      }
    : {}),
  (apiType == 'MongoDB')
    ? {
        // MongoDB RU properties
        apiProperties: {
          serverVersion: serverVersion
        }
      }
    : {})
)

The majority of configs are relevant for all API types and database flavors. Even your check goes over all supported "databases" so it is easy to move it to common configuration.
The key is to not enforce creating "dummy" databases but setup database account correctly also without them.

Having additional discriminator parameter will help and will make the choose transparently to module users.

I hope you consider this improvement.

(Optional) Correlation Id

No response

@dmusic dmusic added Needs: Triage 🔍 Maintainers need to triage still Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue labels Dec 10, 2024

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

Copy link

@dmusic, thanks for submitting this issue for the avm/res/document-db/database-account module!

Important

A member of the @Azure/avm-res-documentdb-databaseaccount-module-owners-bicep or @Azure/avm-res-documentdb-databaseaccount-module-contributors-bicep team will review it soon!

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

  • To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
  • To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

@microsoft-github-policy-service microsoft-github-policy-service bot added the Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days label Dec 13, 2024
@AlexanderSehr
Copy link
Contributor

Hey @bryansan-msft,
Please triage this issue when you get the chance 💪

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Class: Resource Module 📦 This is a resource module Needs: Triage 🔍 Maintainers need to triage still Status: Response Overdue 🚩 When an issue/PR has not been responded to for X amount of days Type: AVM 🅰️ ✌️ Ⓜ️ This is an AVM related issue Type: Feature Request ➕ New feature or request
Projects
Status: Needs: Triage
Development

No branches or pull requests

3 participants