-
Notifications
You must be signed in to change notification settings - Fork 36
Action Required: Namespace migration from Microsoft.Web to Microsoft.App in March 2022 #109
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
Comments
When will the new specs land in https://github.com/Azure/azure-rest-api-specs? I hope it's well before the actual migration of resources, otherwise it's going to break our users of the Pulumi Azure Native provider. |
@anthonychu will this also affect reading existing instances, so will the type of existing ACA instances be modified? If that's the case, I've created a small GitHub Action that customers can use to get a notification once the migration has updated at least one existing instance of their Azure Container Apps https://github.com/ThorstenHans/check-aca-arm-namespace-migration If existing ACA instances were not updated in place, I've to update the Action once again 😄 However, I thought this could be useful. The repo also shows how to have that check being executed every 12 hrs using a cron schedule |
Hi, am I right in my assumption that:
Is there a specific reason that the transition can't be made transparently to the end-users where resources would be available through either API temporarily to allow users more time to manage their migration? Also, it would be useful to know:
|
@mikhailshilkov - The new version branch is ready to be merged to the main branch of azure-rest-api-spec. It should be merged pretty soon. Meanwhile you can find the AP specs here: |
@ThorstenHans - thanks for preparing the github action for this! The way the migration works is that all subscription's environments and containerapps hosted there are migrated at the same time in a given region. After the migration the resources will not be visible in the Microsoft.Web namespace but instead will be visible in the Microsoft.App namespace. So I guess the action could be modified to use the new go client sdk (when it is available) together with the old client sdk to list environments in both namespaces. |
@ruslany correct. That was the intention once the new SDK is there. With the current iteration, I can get an immediate notification when the first ACA is migrated in my sub. Having both SDKs would allow to create a nice listing of all the ACA resources (both migrated and current ones under Microsoft.Web) |
Yes, there will be no transition period when resources are available in both namespaces. However, the portal will work seamlessly with both namespaces and you can continue using it before and after the migration without any noticeable difference. The reason the resources are not available for updates in both namespaces at the same time is because that would violate the ARM requirement that the resource state is updated only via the ARM API calls. For example if an app is created in Microsoft.Web namespace and then updated in the Microsoft.App namespace – the app’s state in the Microsoft.Web will change without any explicit actions performed on that app in that namespace. That will make the ARM cache, Azure Resource Graph and Activity log in Microsoft.Web namespace out of sync with the actual object state. All resources within a subscription in a region will be migrated at once. But resources across regions may be migrated at different times. The specifications for the new Microsoft.App namespace will be merged to the main branch of azure-rest-api-specs very soon. Meanwhile you can see them in a version branch here: azure-rest-api-specs/specification/app/resource-manager at Microsoft.App-2022-01-01-preview · Azure/azure-rest-api-specs (github.com). The API version is still a preview version because we keep iterating on the APIs as new functionality is added. The existing API version from the Microsoft.Web namespace will not be transitioned to Microsoft.App. |
Thanks for the additional detail @ruslany Are you also notifying any active users of the service directly with details of how to migrate? |
@danielrbradley - Yes, we are planning to send notifications to all active users. The notification will reference this github issue which we will be updating with migration details. |
@ruslany What do you recommend authors of tools that use ARM do for our users e.g. I'm one of the maintainers of Farmer and we have had since last year a working implementation of container apps. Obviously if there's a "hard cutover" then some of our users (I imagine this is a relatively small number, but still) will be left high and dry in some way:
Because Farmer removes the need to know how to generate the ARM (or which ARM resources paths are generated), people's Farmer code will be completely unchanged, but the ARM that's generated will suddenly start changing - an situation we're really careful to avoid. The only other idea I have is a period of time whereby we have make users set flag to explicitly upgrade to the new schema, and then after a period of time, remove the flag and make this the default. @forki I believe you might be affected by this. Also looping in @ninjarobot for any other ideas. |
@isaacabraham - the option where user sets a flag to use old or new schema sounds reasonable and should work. I am also wondering if instead of introducing a new flag, the decision to use old or new schema can be driven by what type of an environment is chosen by user. There will be no |
@mikhailshilkov , @danielrbradley - the API specifications are now in the main branch of the azure-rest-api-spec: https://github.com/Azure/azure-rest-api-specs/tree/main/specification/app/resource-manager |
Hey @anthonychu, I'm in the process of migrating my Container Apps Environment and Container App to the new namespace in my Bicep templates and deploying it via GitHub Actions. On the Bicep validation step, I get the following error:
Looking at the API Definition, it looks like the type required for Log Analytics Customer Id is still a string, so has the API Definition been updated as part of this migration or is there something else going on? I've raised the following issue for more details: #126 |
Hi @willvelida - this is a bug in the new PR implementation. We are deploying the fix for it in a next couple of days. |
For anyone using Pulumi to manage their Container Apps can follow this migration guide for managing the transition of resources between namespaces: pulumi/pulumi#9099 |
@willvelida - thanks for the verification! I was about to post here that we've deployed the fix :). You can close the #126 |
When I deployed in the new namespace(Microsoft.App/managedEnvironments), I got the following error.
Curiously, neither LogAnalytics nor ApplicationInsights have been created after the error. These two should have been created before 'Microsoft.App/managedEnvironments' in the dependencies. bicep code is here |
I've deployed into the new namespace (using Bicep), and have noticed a couple of issues:
|
I am having the exact same issue since I migrated the API from |
@takekazuomi , @timoknapp, @davidxw - thanks for reporting these bugs. We are looking into them. The metrics/logging being broken in portal is a known issue as the onboarding of Microsoft.App to metrics is still in progress. |
Likewise, I've just deployed using the new Resource Providers, and refactored some of my old Bicep Files. All looks to work great :) |
Found this bug by trying to attach a container app workspace to a log analytics workspace.
Documentation of It is very hard to comprehend, why documentation has no clue whatsoever as to why this error happens and a lot of developer resources are channeled to spend time figuring yet another puzzler increasing time to market and lowering ROI for the company that is trying to use the technology. It is 2022 and it is time to do things that work according to documentation. |
Hey @askaribragimov, I've just tried to provision an environment with Log Analytics and I got it working. Here's what I did for reference:
Can I ask you how you are extracting the value your $WORKSPACE_ID? That might be causing the issue. |
@willvelida Why the hell workspace ID is also customer ID? Microsoft never ceases to name same thing differently. They should really take AWS example where such thing does not seem to be of issue. |
@askaribragimov resource versions do change over time, so issues like this can occur. Sorry about the inconvenience caused and glad to hear that querying customerId worked for you. @anthonychu - hopefully you're the right person to ask, but the parameter |
@willvelida thank you for the prompt reaction! Apologies that I sound frustrated, it is really confusing what's going on there. |
I got the same issue. Thanks @willvelida for your reference command lines, adding 2 |
Uh oh!
There was an error while loading. Please reload this page.
March 29, 2022 update:
During the month of March 2022, all Azure Container Apps resources will be gradually migrated from the Microsoft.Web namespace to the Microsoft.App namespace.
The availability of your Azure Container Apps resources will not be impacted.
The migration affects how you issue management operations to Container Apps resources — the namespace you use must match the resources you’re updating. If you're using the Azure CLI, you must use a version of the Container Apps extension that is compatible with the resources you’re interacting with.
Migration of existing Container Apps resources
Sometime during the migration period, your Container Apps resources that are in the Microsoft.Web namespace will be migrated to the Microsoft.App namespace. There may be a very short timeframe where Container Apps management requests are unavailable during the migration.
Following the migration, you’ll need to register your subscription with the Microsoft.App namespace before running management operations on your Container Apps resources.
Azure portal
The Azure portal supports managing Microsoft.Web and Microsoft.App resources.
(Update on March 29, 2022) - The Azure portal now creates Microsoft.App resources by default.
ARM and Bicep
If you manage your Container Apps resources using ARM or Bicep templates or by calling ARM APIs, the namespace that you use must match the resources you’re interacting with. After the migration, you need to update your API calls and templates.
The changes for the Microsoft.App namespace are:
2022-01-01-preview
Microsoft.Web/containerApps
resource type toMicrosoft.App/containerApps
Microsoft.Web/kubeEnvironments
resource type toMicrosoft.App/managedEnvironments
kubeEnvironmentId
property tomanagedEnvironmentId
ARM template example:
For complete API specs for Microsoft.App, see this GitHub repo.
Azure CLI
The Azure Container Apps commands in the Azure CLI are currently enabled by a CLI extension. You must use an extension version that is compatible with the namespace of the Container Apps resources you want to interact with.
(Update on March 29, 2022) - To manage resources in the Microsoft.App namespace, install the latest Azure Container Apps CLI extension. Note that the installation instructions have changed. You will not be able to use older version of the CLI extension to manage your resources after the migration.
See #152 for details on this CLI extension release.
Pulumi
If you're using Pulumi, see their migration guide for more details: pulumi/pulumi#9099
Creating new Container Apps resources
Until your Azure subscription has migrated to use the Microsoft.App namespace, you may continue to create Container App Environments in the Microsoft.Web namespace.
When creating new Container Apps, you must use the same namespace as the Container App Environment it’s being created in.
In early March 2022, new Azure Container App Environments created from the Azure portal will use the Microsoft.App namespace. You can manage both Microsoft.Web and Microsoft.App Container Apps resources in the Azure portal. However, when issuing management operations, you must ensure you’re using the correct namespace or a compatible Azure CLI extension version.
See the Migration of existing Container Apps resources section above for more details on what to do when your Container App Environments and Container Apps are migrated.
Frequently asked questions
Can you tell me when my resources will be updated to Microsoft.App?
The migration is performed in batches and we’re unable to provide the exact migration timeframe for your resources.
How will I know when my resources have been updated?
After your resources have been migrated to Microsoft.App, operations using Microsoft.Web will fail with an error such as “Creation or update of environments and container apps in Microsoft.Web namespace are no longer supported. Please use Microsoft.App namespace instead.”
Where can I ask questions related to this migration and get help?
Respond to this issue or create a new issue in this repo. You can also open a case with Azure Support.
The text was updated successfully, but these errors were encountered: