You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CreateOrUpdate: managedenvironments.ManagedEnvironmentsClient#CreateOrUpdate:
Failure sending request: StatusCode=0 -- Original Error:
Code="ManagedEnvironmentInvalidNetworkConfiguration" Message="The environmentnetwork configuration is invalid: Provided subnet must have a size of atleast /23"
Expected Behaviour
Container environment should have been created and delegated to the virtual network subnet defined by the infrastructure_subnet_id argument.
Support of subnet sizes of /27 or larger became generally available August 30th, 2023 for workload profile environments (consumption-only still requires /23).
It might be that the resource needs an additional argument of something like type to differentiate between workload and consumption types. Additionally, the documentation for container_app_environment incorrectly notes "/21 or larger address space" for the infrastructure_subnet_id argument.
Actual Behaviour
Terraform Plan operation succeeds with no indication of an issue. Terraform Apply operation fails with message of "The environment network configuration is invalid: Provided subnet must have a size of at least /23".
Doesn't this rely on workload profiles #22161 - consumption only (the only profile azurerm provider currently supports) still require /23.
Coming back to this; sorry for the delay.
Yes, this requires workload profiles. I wound up getting around this for now by using the azapi provider and passing null to the properties.workloadProfiles property of the JSON body against the resource type of Microsoft.App/managedEnvironments@2022-11-01-preview.
I've been working on an AVM module and have been using AZAPI too, originally because when I started workload profiles weren't supported at all in the azurerm provider. This is how I've implemented it to allow for combinations of consumption & dedicated profiles, open to feedback:
workloadProfiles=var.workload_profiles_enabled?setunion([
{
name ="Consumption"
workloadProfileType ="Consumption"
}],
var.workload_profiles
) :null
There's some examples of usage in the repo too - used for end to end tests.
The approach I'm taking tracks the 'interface' of the azurerm provide from the perspective of the module inputs, under the hood I'm using AzAPI - which is why I've stuck with the variable "workload_profiles", whereas a better name might be 'dedicated_workload_profiles'. I'm hoping that means that as AzureRM matures I'll be able to modify the implementation with minimal-to-no breaking changes, whilst keeping the same module input/interface.
Is there an existing issue for this?
Community Note
Terraform Version
1.4.6
AzureRM Provider Version
3.75.0
Affected Resource(s)/Data Source(s)
azurerm_container_app_environment
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Container environment should have been created and delegated to the virtual network subnet defined by the
infrastructure_subnet_id
argument.Support of subnet sizes of /27 or larger became generally available August 30th, 2023 for workload profile environments (consumption-only still requires /23).
It might be that the resource needs an additional argument of something like
type
to differentiate between workload and consumption types. Additionally, the documentation for container_app_environment incorrectly notes "/21
or larger address space" for theinfrastructure_subnet_id
argument.Actual Behaviour
Terraform Plan operation succeeds with no indication of an issue. Terraform Apply operation fails with message of "The environment network configuration is invalid: Provided subnet must have a size of at least /23".
Steps to Reproduce
No response
Important Factoids
No response
References
microsoft/azure-container-apps#584
The text was updated successfully, but these errors were encountered: