[Bala] Are models and clients tied one to one?

[devigned]

It looks like Models and Clients are tied one to one. It may not be the case. Single Profile version can refer to multiple api-versioned models (meaning latest compute profile might load 2017-06-30 disk model and 2016-03-15 VM model). Just like client, we should also need helper methods for loading(referring) the right object models. I don’t this this initial design handle this.

[devigned]

Great question. The models and clients can be composed at the resource type level of granularity. See: https://github.com/devigned/profile-playground/blob/master/dotnet/src/Azure/Mgmt/Profiles/2017_01_31/Client.cs#L7-L39.

The section of code in that client composes Disk and VM from two different API versions into a single profile.

[balajikris]

Nice! I wonder if there exists a scenario that requires a way to express constraints in composability, for business or technical reasons? Service 'A' version 'x' can be composed with Service 'B' minversion 'a' and maxversion 'b'? Not trying to add complexity but simply wondering about compatibility 😄

[devigned]

Resource types are supposed to be independent. That is, they should not have dependency on other resource types. We've seen this to be partially false with examples such as the inclusion of networking constructs embedded in virtual machine scale set resources (compute).

I think for sanity sake we should try to keep versioning independent as it will just add another facet to an already complex versioning story.

[devigned]

This issue also touches on how to use different API versions from outside of a Profile. To help the discussion, I've added a sample to show how to load API versions of resources from outside of a profile: https://github.com/devigned/profile-playground/blob/master/dotnet/samples/SpecificVersionSample.cs