search

Azure / azure-sdk-for-go

This repository is for active development of the Azure SDK for Go. For consumers of the SDK we recommend visiting our public developer docs at:
https://docs.microsoft.com/azure/developer/go/
MIT License
1.64k stars 842 forks source link

Common Types for Managed Identities #14409

Closed tombuildsstuff closed 7 months ago

tombuildsstuff commented 3 years ago

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:

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 https://github.com/Azure/azure-rest-api-specs/issues/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 commented 3 years ago

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 commented 3 years ago

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

jhendrixMSFT commented 1 year ago

@mikekistler is this something we can address with TypeSpec?

mikekistler commented 1 year ago

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

github-actions[bot] commented 7 months ago

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.