feat: App Service LZA Pattern Module

[ibersanoMS]

Description

Adding initial version of App Service LZA Pattern Module

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[ibersanoMS]

I'm running into quota issues today with my subscription and of course that happens after successfully deploying using the same region for like 2 weeks 😅 That's why the deployment is failing now.

[AlexanderSehr]

Almost there @ibersanoMS 💪
Thank you for your patience. Just 2 last findings + the open question regarding the diagnostics as you did a 180 there. Would just like to understand what your ideal solution would be. Don't feel pressured to change your design just because I called out other modules as references. (:

[AlexanderSehr]

Hey @ibersanoMS,
I can see the quota is still an issue for you. What I'd recommend to do (if you agree) would be to change to target branch of this PR into a dev branch in upstream AVM to retest it in its CI - and then open a final PR from that dev branch to main.
I'd also probably suggest to set a specific location instead of the default WestEuope one as done e.g. here:

bicep-registry-modules/avm/res/cache/redis-enterprise/tests/e2e/amr/main.test.bicep

Lines 21 to 22 in 87386c3

	#disable-next-line no-hardcoded-location
	var enforcedLocation = 'uksouth'

I'd be curious though if you know which resource is the one that fails due to the quota. If needed we may need to raise a quota request on our end too.

[ibersanoMS]

Hey @ibersanoMS, I can see the quota is still an issue for you. What I'd recommend to do (if you agree) would be to change to target branch of this PR into a dev branch in upstream AVM to retest it in its CI - and then open a final PR from that dev branch to main. I'd also probably suggest to set a specific location instead of the default WestEuope one as done e.g. here:

bicep-registry-modules/avm/res/cache/redis-enterprise/tests/e2e/amr/main.test.bicep

Lines 21 to 22 in 87386c3

	#disable-next-line no-hardcoded-location
	var enforcedLocation = 'uksouth'

I'd be curious though if you know which resource is the one that fails due to the quota. If needed we may need to raise a quota request on our end too.

It looks like WestEurope is the issue on my subscription. It's the App Service Premium V3 plans - they're not always avaiable in every region. Should I try hardcoding the location first and then proceed with creating a branch on the main repo?