Support for default workload_profile

[michalkrzych]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Description

Thank you for recently adding support for workload_profile in 3.84

I notice this creates a dedicated profile which needs to be deleted after deployment. While it's not a massive issue I can't see why terraform couldn't support what az cli already does with --enable-workload-profiles.

az containerapp env create -n MyContainerappEnvironment -g MyResourceGroup \
    --location eastus2 --enable-workload-profiles

This enables workload profiles and adds a default Consumption (not to be confused with Consumption Only) so no deletion is required post deployment.

It would be great if we could provide an additional parameter to container_app_environment sort of like this:

resource "azurerm_container_app_environment" "example" {
  name = "my-environment"
  location = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
  **enable-workload-profiles = true**
}

New or Affected Resource(s)/Data Source(s)

azurerm_container_app_environment

Potential Terraform Configuration

resource "azurerm_container_app_environment" "example" {
  name = "my-environment"
  location = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
  enable-workload-profiles = true
}

References

#23478

[kaganmersin]

@rcskosir Is there any update for this issue ? I believe this issue is really crucial since Consumption profile type is one of the fundamental feature of the container apps. I see one PR is still open related this issue.
#24277

[jackofallops]

@rcskosir Is there any update for this issue ? I believe this issue is really crucial since Consumption profile type is one of the fundamental feature of the container apps. I see one PR is still open related this issue. #24277

Hi @kaganmersin et al - The Consumption profile is always present, there can be only one, and it cannot be removed or managed, so it is not managed by the provider at this time (if it becomes removable/changeable, we'll update accordingly). The docs could be clearer on this. Adding to the confusion is that the portal will not display the workload profile option in the blade and display Consumption Only, so it appears to not be there. Adding a workload profile to your Terraform configuration for an existing environment will successfully add this to the resource, and then the portal will also display the option thereafter.

The short version of this is that workload profiles are always enabled behind the scenes, and the cli / portal options are, imo, a little misleading.

Does this help / cover your use case?

Thanks!

[kaganmersin]

Hello @jackofallops

I am aware of the situation that Consumption profile is always present when container app environment were created with at least one workload profile. However in this situation in order to have Consumption profile we should create one dummy workload profile as unneccessary with azurerm provider unlike azapi provider. That is why I believe that having same exact feature/behaviour in azurerm similar to azapi is really crucial as this feature is really fundemental feature of the container apps and it prevent us to have complex modules since we don't have to have dummy workload profiles. Also I see many people waiting for this like me

Also regarding to your following statement ;

Adding a workload profile to your Terraform configuration for an existing environment will successfully add this to the resource, and then the portal will also display the option thereafter.

but when I add new workload profile to the existing Consumption only environment I see the below error:

│ Managed Environment Name: "testenv1"): performing CreateOrUpdate: unexpected status 400 with error: EnvironmentNotCreatedWithWorkloadProfile: To add a new workload profile, environment should be created with a Workload Profile

Thanks !

[jackofallops]

Hello @jackofallops

I am aware of the situation that Consumption profile is always present when container app environment were created with at least one workload profile. However in this situation in order to have Consumption profile we should create one dummy workload profile as unneccessary with azurerm provider unlike azapi provider. That is why I believe that having same exact feature/behaviour in azurerm similar to azapi is really crucial as this feature is really fundemental feature of the container apps and it prevent us to have complex modules since we don't have to have dummy workload profiles. Also I see many people waiting for this like me

Also regarding to your following statement ;

Adding a workload profile to your Terraform configuration for an existing environment will successfully add this to the resource, and then the portal will also display the option thereafter.

but when I add new workload profile to the existing Consumption only environment I see the below error:

│ Managed Environment Name: "testenv1"): performing CreateOrUpdate: unexpected status 400 with error: EnvironmentNotCreatedWithWorkloadProfile: To add a new workload profile, environment should be created with a Workload Profile

Thanks !

Hi @kaganmersin - Thanks for the additional context. When Profiles were first introduced that was not the behaviour we experienced and, unfortunately, a bug in the test coverage for that use case appears to have hidden the failure from us. I'll work with @jiaweitao001 on the implementation of #24277 to correct this behaviour appropriately in the resource.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.