Azure / bicep-registry-modules

Bicep registry modules
MIT License
489 stars 342 forks source link

[AVM Module Issue]: VNET peering not following WAF-naming #2860

Closed john-fox-maule closed 1 month ago

john-fox-maule commented 2 months ago

Check for previous/existing GitHub issues

Issue Type?

I'm not sure

Module Name

avm/res/network/virtual-network

(Optional) Module Version

0.1.8

Description

Naming of peerings is not following recommend abbreviations according to https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations#networking recommend abbreviation is peer

peer actual peers main

(Optional) Correlation Id

No response

microsoft-github-policy-service[bot] commented 2 months 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 months ago

@john-fox-maule, thanks for submitting this issue for the avm/res/network/virtual-network module!

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

microsoft-github-policy-service[bot] commented 2 months 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)!
AlexanderSehr commented 2 months ago

Hey @john-fox-maule, I guess the best would be to add the peer- prefix to the existing name? E.g. peer-vnet1-vnet2 & peer-vnet2-vnet1 Subjectively, I think it's nice to be able to see from where to where the peering is pointing to.

john-fox-maule commented 2 months ago

Hey Yes the peer- should be a prefix in my opinion, however i dont see the point in having the local vnet name listed first it wil always be the same (from where), if you look in the portal you always have the local vnet name, if you list all via scripting it is easy to combine anyway.

AlexanderSehr commented 2 months ago

Hey Yes the peer- should be a prefix in my opinion, however i dont see the point in having the local vnet name listed first it wil always be the same (from where), if you look in the portal you always have the local vnet name, if you list all via scripting it is easy to combine anyway.

Fair point. I was more thinking along the lines of an error message (e.g., via a policy violation) related to the peering where I would not have the VNET name in front of me. But it's a detail. :)