Using workload profiles with ManagedEnvironment throws error code "WorkloadProfileRelatedApiNotSupported"

[brutaldev]

What happened?

When using workload profiles when setting up a AzureNative.App.ManagedEnvironment, it fails with the following error:

error: Code="WorkloadProfileRelatedApiNotSupported" Message="This api is supported from 2022-11-01-preview api-version and above."

The documentation (https://www.pulumi.com/registry/packages/azure-native/api-docs/app/managedenvironment) examples shows usage of the WorkloadProfiles property but this sample will not work. The documentation also indicates that the underlying API version being used is 2022-10-01 while it appears workload profiles requires at least 2022-11-01-preview.

Expected Behavior

Should be using the latest API version when creating container app environments in order to use new features.

Steps to reproduce

Try to create a container apps environment using workload profiles:

new AzureNative.App.ManagedEnvironment("wp-bug", new()
{
    ResourceGroupName = "Test",
    Location = "westeurope"
    WorkloadProfiles = new[]
    {
      new AzureNative.App.Inputs.WorkloadProfileArgs
      {
        // Name = "?"  // Will need to set the name in order to link apps.
        WorkloadProfileType = "D4",
        MinimumCount = 1,
        MaximumCount = 10,
      }
    }
  }
}

Output of pulumi about

CLI
Version      3.78.1
Go Version   go1.20.7
Go Compiler  gc

Plugins
NAME    VERSION
dotnet  unknown

Host
OS       Microsoft Windows 11 Pro
Version  10.0.22621 Build 22621
Arch     x86_64

This project is written in dotnet: executable='C:\Program Files\dotnet\dotnet.exe' version='7.0.400'

Additional context

Same bug in the Azure Dev repo: Azure/azure-dev#2402
Fix in the Azure Dev repo: Azure/azure-dev#2412
Could be useful in resolving this: #2467
Bicep example: https://github.com/microsoft/azure-container-apps/blob/main/docs/templates/bicep/workloadProfiles/managed-env-workload-profiles.bicep

The latest API version for this is 2023-05-01 and removes WorkloadProfileType in favour of 1WorkloadProfileName1 when linking a container app toa profile. The Pulumi API for container app (https://www.pulumi.com/registry/packages/azure-native/api-docs/app/containerapp/) would need to be updated to align with this as well. WorkloadProfileArgs is missing the name property argument.

Suggestion: WorkloadProfileType can be an enum for:
General Purpose: D4/8/16/32 or Memory: E4/8/16/32

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[brutaldev]

Found a workaround by using the versioned namespace:

new AzureNative.App.V20230501.ManagedEnvironment("wp-bug", new()
{
    ResourceGroupName = "Test",
    Location = "westeurope"
    WorkloadProfiles = new[]
    {
      new AzureNative.App.V20230501.Inputs.WorkloadProfileArgs
      {
        Name = "GeneralPurposeD4Node",
        WorkloadProfileType = "D4",
        MinimumCount = 1,
        MaximumCount = 10,
      }
    }
  }
}

[danielrbradley]

Hi @brutaldev thanks for logging this. Yes your workaround looks good.

What version of the azure-native provider are you using? It looks like you're on version 2.x?

Side note: I agree this issue is relavant to #2467 because that would make it possible to pick the exact desired API version.

If I understand the issue correctly, I don't think this is a bug with the provider because we're interacting correctly with the chosen API version. Rather this is indicating that: to use a certain feature you need to use a newer version than the listed default version, which you were able to do.

I'm therefore going to close this as resolved. Please do let me know if I've misunderstood the issue you were raising.

[brutaldev]

Hi @danielrbradley

What version of the azure-native provider are you using? It looks like you're on version 2.x?

Using the latest at the time of writing, 2.3.0

If I understand the issue correctly, I don't think this is a bug with the provider because we're interacting correctly with the chosen API version. Rather this is indicating that: to use a certain feature you need to use a newer version than the listed default version, which you were able to do.

Correct, by going through the repo to look for ways to potentially inherit or override things I noticed the API version directories/namespaces. So although it would be nice to set the version, it's even better having the strongly typed namespaces available to pick the one you want.