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

A method to ensure Express Route Connections are not removed with vwanConnectivity module #740

Open
2 tasks done
DavidLHannah opened this issue Mar 14, 2024 · 2 comments
Open
2 tasks done
Labels
Needs: Attention 👋 Needs attention from the maintainers Type: Enhancement ✨ New feature or request

Comments

@DavidLHannah
Copy link
Contributor

DavidLHannah commented Mar 14, 2024

Describe the feature end to end, including deployment scenario details under which the feature would occur.

We need a method where we can ensure that ExpressRoute Connections are not removed when redeploying our code, when using the vwanConnectivity module.

After we have deployed an Azure vWAN infrastructure via vwanConnectivity, we may use the hubPeeredSpoke orchestration module or some other method to peer vNets to our vWAN. When we redeploy the vwanConnectivity code , peering to our vNets does not get removed and network connectivity remains active between spokes during the deployment process.

In a production environment, we'd expect the expressRouteConnections should survive an updated deployment that does not explicitly nullify the connections. There should be a similar type of continuity for the ExpressRoute Connections.

Why is this feature important. Describe why this would be important for your organization and others. Would this impact similar orgs in the same way?

Our infrastructure includes the use of the vwanConnectivity module, deploying a vWAN Virtual Hub along with an ExpressRoute Gateway.

When redeploying our code, ExpressRoute Connections which have been added to our ExpressRoute Gateway get removed. This appears to occur because the resErGateway resource does not include the expressRouteConnections parameter.

Even if we decide to deploy an expressRouteConnections resource in subsequent code, the initial deploy of vwanConnectivity module will cause down-time between Azure and our ExpressRoute sites until the expressRouteConnections is deployed.

We need to be able to deploy updates to our vWAN environment via IaC without causing this kind of unnecessary downtime. This may be similar, or related to the issue discussed in #727 .

The VPN Gateway may benefit from a similar enhancement as well.

Can you describe any alternatives that you have taken since this feature does not exist?

Using a read only Resource Lock on the ExpressRoute Gateway will successfully prevent the removal of the Connections, but the deployment may otherwise fail due to the lock.

Feature Implementation

  • We could potentially provide the expressRouteConnections parameter on the Hub object and pass it to the ExpressRoute Gateway. Although I am not sure if a scenario like this could improperly involve a reference loop.
  • Some other Flag or Switch that would alter logic in the vwanConnectivity module, potentially reference the existing ExpressRoute Gateway?

Check previous GitHub issues

  • I have searched the issues for this item and found no duplicate

Code of Conduct

  • I agree to follow this project's Code of Conduct
@DavidLHannah
Copy link
Contributor Author

Following up here with additional detail.

I was initially running into this issue while using a previous version of ALZ-Bicep. This was done by including the vwanConnectivity among a larger infrastructure which would also create a Resource Lock. Noticing that Resource Lock functionality had since been added, I updated to release v0.17.2 as well as the fix on this issue #743

When utilizing a ReadOnly resource lock on the ExpressRoute Gateway, we will need to set the lock kind to Delete before adding our required ExpressRoute Connection, then set the kind back to ReadOnly.

Upon deploying unrelated updates that are part of the larger infrastructure included in the vwanConnectivity module, the deployment will not affect our existing ExpressRoute Connections, as desired. However, the deployment ultimately fails.

This is as expected, producing the ScopeLocked error. There is still a need here for us to be able to deploy environment updates via IaC, without causing down-time due to the removal of the ExpressRoute Connections.

@oZakari
Copy link
Contributor

oZakari commented Mar 20, 2024

Hey @DavidLHannah, thanks for providing all of the details and sorry for a frustration! I am looking into to see if we can add a ternary null value or potentially make use of the contains function so that the express route connections property won't try to revert your configuration. You can then incorporate the https://github.com/Azure/bicep-registry-modules/tree/main/avm/res/network/connection resource to provision the ExpressRoute Connection resource.

@oZakari oZakari added the Needs: Attention 👋 Needs attention from the maintainers label Mar 20, 2024
@oZakari oZakari added Type: Enhancement ✨ New feature or request and removed enhancement labels Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Attention 👋 Needs attention from the maintainers Type: Enhancement ✨ New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants