[AVM Module Issue]: Quality of Life for DBforMySQL/flexibleServers

FallenHoot commented 2 weeks ago

Check for previous/existing GitHub issues

[x] I have checked for previous/existing GitHub issues

Issue Type?

Feature Request

Module Name

avm/res/db-for-my-sql/flexible-server

(Optional) Module Version

No response

Description

I’m really looking for is a self-healing mechanism that operates behind the scenes. Specifically, I want the module to avoid errors when I choose the Burstable tier for cost reasons, even though this requires disabling storageAutoGrow. On the other hand, if I select a different tier and want to keep storageAutoGrow enabled, I want everything to function smoothly. storageAutoGrow must be disabled if Burstable tier is used as it is not supported.

This is viable for when I am doing code testing or a PoC, because I want to keep cost down as I rip the workload up/down.

My suggestion would be something like this but would need to be verified if it works.

// Ensure highAvailability is set to 'Disabled' if tier is 'Burstable'
var effectiveHighAvailability = (tier == 'Burstable') ? 'Disabled' : highAvailability

// Ensure storageAutoGrow is disabled if tier is 'Burstable' and highAvailability is 'SameZone' or 'ZoneRedundant'
var effectiveStorageAutoGrow = (tier == 'Burstable' && (highAvailability == 'SameZone' || highAvailability == 'ZoneRedundant')) ? 'Disabled' : storageAutoGrow

var standByAvailabilityZoneTable = {
  Disabled: null
  SameZone: availabilityZone
  ZoneRedundant: highAvailabilityZone
}

var standByAvailabilityZone = standByAvailabilityZoneTable[effectiveHighAvailability]

storageProfile: {
      storageMB: 51200
      backupRetentionDays: 7
      geoRedundantBackup: 'Enabled'
      autoGrow: effectiveStorageAutoGrow
    }
highAvailability: (effectiveHighAvailability != 'Disabled') ? {
      mode: effectiveHighAvailability
      standbyAvailabilityZone: standByAvailabilityZone
    } : null

Self-Healing Mechanism Avoiding Errors: By conditionally setting effectiveHighAvailabilityand effectiveStorageAutoGrow, the code ensures that unsupported configurations (like enabling storageAutoGrowwith the Burstabletier) are automatically adjusted to avoid errors. Smooth Functionality: When a different tier is selected, the code allows storageAutoGrow to be enabled and configures high availability settings appropriately, ensuring smooth operation without manual intervention. Behind-the-Scenes Operation: The use of conditional expressions and mappings allows the module to automatically adjust settings based on the selected parameters, providing a self-healing mechanism that operates transparently to the user.

This approach ensures that the MySQL server configuration is always valid and optimized for the selected tier and high availability settings, preventing errors and maintaining smooth functionality.

(Optional) Correlation Id

No response

microsoft-github-policy-service[bot] commented 2 weeks ago

[!IMPORTANT] The "Needs: Triage :mag:" 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.

avm-team-linter[bot] commented 2 weeks ago

@FallenHoot, thanks for submitting this issue for the avm/res/db-for-my-sql/flexible-server module!

[!IMPORTANT] A member of the @Azure/avm-res-dbformysql-flexibleserver-module-owners-bicep or @Azure/avm-res-dbformysql-flexibleserver-module-contributors-bicep team will review it soon!

microsoft-github-policy-service[bot] commented 1 week ago

[!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 :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

microsoft-github-policy-service[bot] commented 5 days ago

[!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 :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

microsoft-github-policy-service[bot] commented 5 days ago

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!

Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

Azure / bicep-registry-modules