kubernetes: StorageClass should not be in the extensions group
The extensions group isn’t meant to be an incubator group, its intended to hold the things already in it, resources directly related, and thirdpartyresource. We’ve actually gone to some effort to migrate some types out: HPA and Jobs as a for instance.
Different APIs want to move at different cadences and new resources should start off in an alpha version while they sort out what they really need during their implementation phases.
We tagged an alpha of 1.4, but I think we should move these resources into their own group. I suspect they’ll want new versions at a cadence to match the storage controllers, not a cadence locked to the rest of the extensions API.
@childsb @kubernetes/rh-cluster-infra @kubernetes/sig-api-machinery
Assigned to @lavalamp so he’ll be sure to notice and weigh in here, not as a final destination.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 39 (39 by maintainers)
Do we want to repurpose this as “discuss apigroup versioning” ?
Right. That combined with a preference ordering of versions that places “alpha” last would allow clients to find the latest stable version of a resource if it exists, the latest bleeding edge if they want, and by having sparse versions we’ll get to eliminate duplication between versions.