Common Types for Managed Identities

[tombuildsstuff]

Feature Request

Managed Identities are of a predefined type at this point in time (although they appear to be missing from the API contracts) - they're some combination of:

• None
• System Assigned
• System Assigned, User Assigned
• User Assigned

As such these could form a common type in Azure/go-autorest which would enable both code re-use for consumers of the SDK - and validation/generation errors for Swaggers which didn't match the common definitions (as seen in Azure/azure-rest-api-specs#13340). At present these are instead uniquely generated per-type and not necessarily complete (see that Github issue for one example) - so this could be consolidated since this is a common convention/defined type.

In short: can the SDK expose common types for these, rather than a type (or multiple types) per service/struct?

Thanks!

[ArcturusZhang]

Hi @tombuildsstuff thanks for this issue

This is a very good idea and we also have considered that. But it might not be ideal when we are actually trying to implement this.
The difficulty comes from the swaggers - despite we have the common-types predefined here, the author of a swagger PR might not be using them.
Roughly we have the following 3 circumstances:

1. the swagger is using the types from common-types (assuming we have a way to identify this from the 2nd circumstance). It is possible to use the common-types in a common package.
2. the swagger is using a self-defined common-types, but those are identical to the ones in common-types. We could do similar things as in 1st circumstance by treating them as duck types.
3. the swagger is using a self-defined common-types, but those are not identical to the ones in common-types. We have this case a lot in our current swaggers - usually the differences are in the descriptions. In this case, we could do nothing - because the code generator has no knowledge on what this property means. (maybe we could introduce more extensions?)

Also there are concerns that if the service team chooses to define their own types, there are possibilities that they might change the definition in the future. For example they might add a property. Previously this is not a breaking change, but if we once identify this as a common-type by treating it as a duck type, this change will become a breaking change.

@jhendrixMSFT thoughts?

[lirenhe]

@jhendrixMSFT , do you have any thinking for this ask?

[jhendrixMSFT]

@mikekistler is this something we can address with TypeSpec?

[mikekistler]

There is no provision for this in TypeSpec, as best I am aware.

[github-actions]

Hi @tombuildsstuff, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.