Microsoft.App/managedEnvironments@2022-11-01-preview Managed Environment deployment fails after initial deployment

[ChrisTrailight]

Bicep version: 0.16.2

When deploying a container app to a managed container app environment configured to use a workload profile of 'Consumption', after the first deployment, subsequent deployments fail with the error

{
    "status": "Failed",
    "error": {
        "code": "WorkloadProfileInUse",
        "message": "Cannot remove workload profile(s): Consumption because it is being used by container apps"
    }
}

Expected behaviour:

The container app environment deployment would either succeed or have its state updated depending on the template inputs and then succeed

Steps to reproduce:

• Create a bicep template that deploys: a managed container app environment using the Microsoft.App/managedEnvironments@2022-11-01-preview API, configured with a workload profile of 'Consumption', that runs a container app.
• deploy the template
• redeploy the template

bicep snippet:

resource managedEnvironment_name_resource 'Microsoft.App/managedEnvironments@2022-11-01-preview' = {
  name: managedEnvironment_name
  location: location
  properties: {
    vnetConfiguration: {
      internal: true
      infrastructureSubnetId: resourceId('Microsoft.Network/virtualNetworks/subnets', vnet_name_resource.name, ContainerAppSubnet)
    }
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: LogAnalytics_resource.properties.customerId
        sharedKey: LogAnalytics_resource.listkeys().primarySharedKey
      }
    }
    workloadProfiles: [
      {
        workloadProfileType: 'Consumption'
      }
    ]
    zoneRedundant: false
    customDomainConfiguration: {}
  }
}

[brwilkinson]

Hi @ChrisTrailight

I believe you have come across a bug related to the new featureset, which is only available in api 2022-11-01-preview

• Also it's not easy to see the correct settings that may workaround the bug, since the API has not been published.

This is still marked as preview and was just recently announced:

• https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-container-apps-announces-new-pricing-plan-and-enhanced/ba-p/3790723
• https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview
  • which is also why it's only available in select regions.

Given it's preview I would recommend the following ...

1) Search and then open an issue over here:

• https://github.com/microsoft/azure-container-apps/issues 1) Paste your open issue link back here for reference. 1) Consider to also open a support ticket against the service in the portal (perhaps only if you don't get a response on 1 above)

1) You could just mix the Consumption with Dedicated for testing for now, until it's resolved.

- I also tested with a dedicated D4, scaled down to min and max of 1 node, then only deployed apps to the consumption, it seems having the second dedicated plan was enough to bypass (workaround) the error. Not ideal, however given it's preview, at least this could unblock your testing.

on your ManagedEnv, add the following.

workloadProfiles: [
    {
      workloadProfileType: 'Consumption'
      name: 'Consumption'
    }
    {
      workloadProfileType: 'D4'
      name: 'Dedicated-D4'
      minimumCount: 3
      maximumCount: 5
    }
  ]

on your container app, add the following.

properties: {
    managedEnvironmentId: managedENV.id
    workloadProfileName: containerAppInfo.?workloadProfileName ?? null

e.g.

properties: {
    managedEnvironmentId: managedENV.id
    workloadProfileName: 'Dedicated-D4'

Example of even scaling to 1 / 1

[brwilkinson]

@ChrisTrailight okay adding more info, I was able to find the cause of the issue.... again, this would likely be revealed once the schema is published.

workloadProfile name should be required without it you will get the error, however with the name, it works as expected.

    workloadProfiles: [
      {
        workloadProfileType: 'Consumption'
        name: 'Consumption' // <-- required
      }
    ]

I think it's still worth opening the issue against that other repo on this, would you mind doing that?

[alex-frankel]

Moving this to bicep-types-az, but agree opening a separate issue in the repo @brwilkinson mentioned would be the right next step to get this resolved.

[ChrisTrailight]

Thank you very much @brwilkinson. Have tested and confirmed the fix. Specifying the name parameter in the workloadProfile declaration allows the deployment to succeed against an existing resource. I have opened the issue with the container apps team as requested. Thanks again for your help.