runtimeSubnetId not used? No IP addresses are used when deploying an app

[cwe1ss]

This issue is a:

• bug report -> please search issues before submitting
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Issue description

When connecting an app environment to a VNET, no IPs are used from the "runtimeSubnetId".

Steps to reproduct

1. Create a VNET with two subnets (the first one for infrastructure, the second one for runtime)
2. Assign those subnets to "infrastructureSubnetId" and "runtimeSubnetId" on the environment "vnetConfiguration" (internal: false)
3. Deploy an app
4. Call the app URL to ensure it's running
5. Look at "connected devices" on the VNET or run (Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $groupName -ExpandResource 'subnets/ipConfigurations').Subnets[1].IpConfigurations.Count.
6. There are no IPs used from the runtime subnet. (wheres the infrastructure-subnet is using 183 ip addresses)

Expected behavior [What you expected to happen.]
I expected the app to take an IP address from the runtime subnet since its documentation says "Resource ID of a subnet that Container App containers are injected into."

Actual behavior [What actually happened.]
No IPs are used from the "runtimeSubnetId". I have no idea which IP address has been given to the app.

Screenshots

I noticed that when you look at the environment in the Azure portal's resource explorer, the "runtimeSubnetId" property is not returned but the property does show up in the deployed template details.

Deployed template:

View from resource explorer:

(PS: Note that this also doesn't show the dapr* fields for some reason, but dapr does log dependency calls to Application Insights)

[ezYakaEagle442]

The “runtime subnet” field is currently deprecated and not used. If you provide a value there during creation of your container apps environment it will be ignored. Only the infrastructure subnet is required if you wish to provide your own VNET.
see

• https://github.com/ezYakaEagle442/aca-java-petclinic-mic-srv/blob/main/iac/bicep/aca/pre-req.bicep#L46
• https://github.com/ezYakaEagle442/aca-java-petclinic-mic-srv/blob/main/iac/bicep/aca/pre-req.bicep#L172

[kendallroden]

To echo the above, the runtime subnet is not required and the updates are reflected in our documentation

[cwe1ss]

Thank you for the information!

Would be great if you could document this in the Bicep/ARM reference as well - it's not deprecated there yet:

https://docs.microsoft.com/en-us/azure/templates/microsoft.app/managedenvironments?pivots=deployment-language-bicep

[praneetloke]

Yeah I was misled as well from looking at the Bicep/ARM reference. I don't see a way to contribute edits to that page. It would be good to patch that up as well.

[jimseld]

Doc still isn't updated regarding deprecation of runtimeSubnetId, for both ARM and Bicep.

https://learn.microsoft.com/en-us/azure/templates/microsoft.app/managedenvironments?pivots=deployment-language-arm-template

[miqm]

And now the deployment fails - the 2022-03-01 API still defines this property. This is a breaking change and it shouldn't be done like that. You may ignore but you shuldn't change API backwards!

On one case you (Microsoft) cannot make a change for vnet empty subnets property behavior for 7 years(!), but here you make a deployment breaking change and you don't even care to update docs.

I don't see any logic here.

cc: @bmoore-msft

[bmoore-msft]

Sorrym no ideas - this one is even odd for me?!?