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

Error when deploying Enterprise-Grade Edge if custom domain is linked to prior AFD resource #691

Open
chrisreddington opened this issue Jan 18, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@chrisreddington
Copy link

The Enterprise-Grade Edge for Azure Static Web Apps does not work correctly if the desired hostname is already assigned to another Azure Front Door instance. The enabling works 'correctly', but fails to map to the correct instance when the app is live. In my scenario, I happened to have an Azure Front Door instance left over from a prior deployment and hadn't fully cleaned it up, hence encountered this issue.

To Reproduce (e.g. Azure Front Door and Azure Static Web Apps)

  1. Deploy an instance of Azure Front Door (either classic or ADFX provides same outcome). Deploy an Azure Static Web App with the standard SKU.

  2. To simulate the issue, configure the custom domain that you plan to use with Enterprise-Grade Edge on your Azure Front Door instance. Associate that domain with a route.

    image

  3. Re-map your DNS record to the Azure Static Web App and enable the custom domain on the Static Web App. Set this custom domain as the default for your SWA.
    image
    image

  4. Using either the Azure CLI or Azure Portal, enable the Enterprise-Grade Edge capability. In my repro environment, the feature eventually silently fails.

    image

  5. Looking in the activity log, I can see that the enterpriseGradeCdnStatus went from Enabling to Disabled.

  • Interestingly, if I try to re-enable the Enterprise-grade edge in this scenario - I get a notification saying that the process is still ongoing (while the blade UI no longer shows that it is enabling)

    image

  • This is an interesting difference to what I was seeing previously. Before, it enabled successfully but when viewing the domain - the page did not display the expected result. Instead, It showed a webpage with a message along the lines of "That the resource has moved/name changed/ temporarily unavailable".

To reproduce (E.g. Two Azure Front Doors without Static Web Apps to understand the behaviour)

  1. Deploy an instance of Azure Front Door (either classic or ADFX provides same outcome) (You can re-use the existing deployment from the above scenario). Deploy a second Azure Front Door instance (e.g. ADFX or Classic). Deploy an Azure Static Web App with the standard SKU.

  2. To simulate the issue, configure a custom domain on your first Front Door instance. If you're re-using the AFDX from the scenario above, then you already have this configured.

  3. Delete any existing DNS Record for the domain you plan to configure (including validation records such as _dnsauth for that domain entry) that you plan to configure on your second Front Door instance.

    image

  4. You will encounter an error that the custom domain failed to create, but no reason why.

    image

My suspicion is that Azure Front Door detected the custom domain configured on another Azure Front Door instance, and bound to a route in that AFDX instance, hence failing the creation. My hypothesis/suspicion is that this caused me issues when trying to enable the Enterprise-grade Edge capability in Azure Static Web Apps.

Expected behavior

  • An error explaining that the hostname is already mapped on another Azure Front Door resource (ideally calling out which resource).
  • The 'enabled' feature to be rolled back/blocked from being enabled. Once you retry enabling, it should start the process again (rather than being in an inconsistent cleanup state).
  • A clear and detailed walkthrough to migrate from a previous Azure Front Door setup to the Enterprise-grade edge setup.

Device info (if applicable):

  • OS: Windows 11 / macOS 11.6.2
  • Browser: Edge

Additional context
N/A - Hope the above detailed walkthrough gives some additional insight. This may be quite an edge-case. However, I wanted to raise it in case people have used either Azure Front Door classic or AFDX and are planning to migrate to using Enterprise-grade edge. It'll be important to have a consistent and well-documented migration path.

@chrisreddington chrisreddington changed the title Error when deploying to Enterprise-Grade Edge Error when deploying Enterprise-Grade Edge if custom domain is linked to prior AFD resource Jan 18, 2022
@miwebst
Copy link
Contributor

miwebst commented Jan 18, 2022

Hey Chris, thanks for bringing this up! Yes unfortunately you cannot enable the feature if the domain is already attached to an existing AFD instance. I think your expected behavior notes are valid and we will see what we can do to fix this in the long term.

In the short term, the only way to switch over is to remove the custom domain from AFD and then enable Enterprise-grade edge.

@milanm
Copy link

milanm commented Nov 16, 2023

This issue still persists.

@Allislove
Copy link

Yeah, still persists is hard to activate this

@Allislove
Copy link

Hey Chris, thanks for bringing this up! Yes unfortunately you cannot enable the feature if the domain is already attached to an existing AFD instance. I think your expected behavior notes are valid and we will see what we can do to fix this in the long term.

In the short term, the only way to switch over is to remove the custom domain from AFD and then enable Enterprise-grade edge.

What do you mean? Should we first remove all our custom domains added to that static web application, and then would we be able to activate the enterprise-grade?

Best Regards,
Andrés Romaña

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants