don't register non-core types into scheme #219
Conversation
Move that logic into the codec creation util.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: joelddiaz The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
What is the reasoning for this? Aren't the provider types part of the API? For example, isn't the |
This was just something I noticed while trying to move things to openshift/api. I saw us registering these generically-named objects, and noticed that some where missing (Ovirt and OpenStack). So since the code was working without needing to register these types, why register them (to be clear, I'm genuinely asking this question)? Perhaps I'm missing the bigger picture, but what does registering types that we cannot directly query out of etcd get us feature-wise (since we have to go through the codec to unpack these provider types)? |
|
After some more discussion this approach would be considered non-idiomatic and may end up surprising someone consuming CCO's API objects. Closing. |
|
@staebler @dgoodwin let's revisit this PR. It looks like from the comments at openshift/api#683 (comment) , that there is some surprise that we're registering some of our embedded types. And it would make for a cleaner migration into openshift/api if we resolved this in CCO before attempting to migrate our types to openshift/api. |
|
/retest |
|
lets look into removing these from pkg/api (so they aren't part of what is submitted to openshift/api). |
3 participants
Move that logic into the codec creation util.