Container Apps: vnet configuration, custom domains and removing obsolete arm properties

Hey Farmers,

loving this lib, thank you so much for building a project like this! ❤️

We’d like to use it with container apps (i.a.) and noticed vnet configuration and custom domains (via Ingress) to be missing. (ref #993)

I’d like to add support for these, but also noticed the ManagedEnvironment.JsonModel method is emitting some ARM that might be in conflict since the API has been replaced. Specifically internalLoadBalancerEnabled, which seems to have been copied from the old Microsoft.Web/kubeEnvironments. I’m also a little confused about the type field, according to the MS docs there used to be one called environmentType, I guess it was renamed at some point?

So I was wondering how I should implement this. Would it be ok to update the resource version and remove/replace the outdated API with the new one? I don’t think we can migrate the old field to the new API, since it requires a vnet and subnets to be set in vnetConfiguration.

What about default values and required fields? The MS docs are not exactly clear on many things (or I didn’t find it). For the subnets I guess I’d split them like the ContainerGroups Builder into vnet/subnets.

Ingress for the Domains seems to be very minimal at the moment and would need to be extended. This is currently implemented in Common, which is probably fine for the smaller settings, but with Ingress becoming larger and nested, should it be moved to Builders? The app’s custom domain setting would need to reference a new resource type, Microsoft.App managedEnvironments/certificates, so that would need to be reachable by the Ingress type.

[stroborobo]

Hey, I’ll have to delay this a little longer, sorry. I’m still determined to do this and Im going to keep your words in mind, but I need an emergency vacation right now, I hope you understand.

[ninjarobot]

The API version and the underlying resource are updated independently. When you specify the apiVersion, you are telling ARM what format your requests will be in so it knows how to route it to the correct internal resource provider endpoint and so the RP itself knows how to deserialize requests and serialize responses.

Redeploying existing resources using a new API version is intended to be no different than redeploying with the existing API. The resource provider deserializes the payload and checks for changes with the existing resource, then applies only what is changed. The API version would only affect how it goes about deserializing and validating the payload.

I expect this is even the case with a total change of resource type as was done with container apps, although I don’t personally have one created with the original resource type and API to be able to verify this. That team had to go through a whole migration project that would repopulate the ARM resources so they would appear under the new type, but the actual underlying Kubernetes environment would remain the same.