Customization for arm build-in model's visibility and optional setting for resource properties property

[tadelesh]

For current ARM resource model the properties property is optional and with visibility read and create, but existed RP's swagger may have different setting for them. Other than redefine a new ProxyResource model, is there other way to do customization for them?
e.g.: https://github.com/Azure/azure-rest-api-specs/blob/05c4049bc22f0ec65acc18f9835132397049cb9e/specification/elasticsan/resource-manager/Microsoft.ElasticSan/stable/2023-01-01/elasticsan.json#L1652

[markcowl]

Because the typing of templates is structural and not nominal, you can use your own resource types if you want a different 'properties' optionality/visibility.

The optionality and visibility in the templates is based on current LintDiff rules and required behaviors for RPaaS clients, so there is a disincentive to update the templates.

Need to understand how this impacts management client generation before we think about adding an extra degree of freedom to templates, but because a custom resource type should work just fine, this should not be blocking.

[tadelesh]

It will cause breaking change for lots of languages as required property will become a param in default model ctor. Confirm that custom resource type could resolve it. But it seems this is a common issue for lots of existed swaggers. To prevent too much manual work, I'm going to change conversion logic not to use predefined resource template, instead extends predefined resource base and alway add properties property separately.

[markcowl]

I think this is related to the inheritance hierarchy for resources as well: #104 - given how many resources don't conform to the represented TrackedResource/ProxyResource/ExtensionResource hierarchy, we may not want to use the existing model templates anyway

[markcowl]

@markcowl ensure that swagger converter has a clear path to avoid breaking client changes

[MaryGao]

@tadelesh @markcowl could you help me understand on how this issue is going to resolve?

In our case the impacted properties are id and type in Resource type. In swagger they are 1) all optional and 2) sub types could change to required ones if wanted. In typespec they are all required and no way to change the optionality.

• swagger https://github.com/Azure/azure-rest-api-specs/blob/main/specification/common-types/resource-management/v5/types.json#L14-L29
• typespec https://github.com/Azure/typespec-azure/blob/main/packages/typespec-azure-resource-manager/lib/arm.foundations.tsp#L23-L32

This would cause a big breaking for JS(here) and I was wondering how we could mitigate this.

[tadelesh]

If service team insist on setting visibility and optionality which is different from current arm template, we will use customized definition to define the resource which will make the visibility and optionality correct.

[MaryGao]

Thanks and it works for me!