StorageClass should not be in the extensions group

[deads2k]

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.

[deads2k]

Introduced in #29694, types here: https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/extensions/types.go#L924

[liggitt]

storage.k8s.io/v1alpha1 or something like it would be better

[deads2k]

storage.k8s.io/v1alpha1 or something like it would be better

I think that makes a lot of sense. That group would be the final resting place of PV and PVC for their next rev to help us retire the legacy API group.

[thockin]

a) StorageClass is beta, not alpha

I will paste my messages from the other thread:

In this particular case, we could make a new group, but in general we
will sometimes want to add a new beta Kind to an extant v1 group. We
are not going to revive v1beta1 for the group, nor do we want (I think) to bump
to v2beta1 for every new Kind. So we need a place to grow things.

We need an answer to this whole problem in general. I am not happy
with the way apigroups has turned out - it's far less flexible than I
think we wanted, and far too cumbersome to use.

[smarterclayton]

API groups is required in order to have extension API resources (unless we
go resource by resource, and even then you need some grouping). I agree
the process we are using to decide how things go into groups and versions
and iterate through them is questionable.

I don't think we necessarily have to treat groups as "all kinds must be in
it". For instance, adding a new resource "Foo" to a group doesn't mean it
needs to go in any version except "v1alpha1" (even if that group is up to
v2). It just means you need to use the generated v1alpha1 client to access
the resource.

On Fri, Aug 26, 2016 at 1:00 PM, Tim Hockin notifications@github.com
wrote:

a) StorageClass is beta, not alpha

I will paste my messages from the other thread:

In this particular case, we could make a new group, but in general we
will sometimes want to add a new beta Kind to an extant v1 group. We
are not going to revive v1beta1 for the group, nor do we want (I think) to
bump
to v2beta1 for every new Kind. So we need a place to grow things.

We need an answer to this whole problem in general. I am not happy
with the way apigroups has turned out - it's far less flexible than I
think we wanted, and far too cumbersome to use.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p9qqmgm4UGFgyL22Gk-sQRfgFbknks5qjxuqgaJpZM4JuI0k
.

[thockin]

So in this case, if I were adding something to batch which is already at v1, my new thing would exist in batch/v1beta1 but the rest of batch would not? Isn't that essentially per-kind versioning?

Are we really in uncharted space here? Is there no established best practice for this in REST-ville?

[deads2k]

In this particular case, we could make a new group, but in general we
will sometimes want to add a new beta Kind to an extant v1 group. We
are not going to revive v1beta1 for the group, nor do we want (I think) to bump
to v2beta1 for every new Kind. So we need a place to grow things.

My objection isn't to adding a type to an existing version of an API group. I'm concerned about using this particular group as a catchall for "I'm going to want a new API group, but this is a convenient place at the moment for a type that doesn't belong in this group in the end".

so if we had "incubator" instead of "extensions" you'd be less unhappy?

Marginally. I still think that if you know you have a kind that belongs in a new API group, you should create that API group. In this case, StorageClass looks like a natural fit with PersistentVolume and PersistentVolumeClaim. I would expect a storage.k8s.io API group that eventually contains all three, but could start with just the new one StorageClass.

[thockin]

I think we need a systemic decision about this INCLUDING the "I want to add
a kind to an existing group that is at v1". And if the decision is to rev
the whole group to v2beta1, we need some serious SERIOUS streamlining.
This is not something that we can ask a community member at-large to do
(even just adding a new group, much less reving an existing group is way
too hard).

I am not in charge of UX, I'm just a jerk with opinions. I will adhere to
what Real Experts think is best.

@bgrant0607 @smarterclayton @lavalamp - UX/API decision needed.

On Fri, Aug 26, 2016 at 10:29 AM, David Eads notifications@github.com
wrote:

In this particular case, we could make a new group, but in general we
will sometimes want to add a new beta Kind to an extant v1 group. We
are not going to revive v1beta1 for the group, nor do we want (I think) to
bump
to v2beta1 for every new Kind. So we need a place to grow things.

My objection isn't to adding a type to an existing version of an API
group. I'm concerned about using this particular group as a catchall for
"I'm going to want a new API group, but this is a convenient place at the
moment for a type that doesn't belong in this group in the end".

so if we had "incubator" instead of "extensions" you'd be less unhappy?

Marginally. I still think that if you know you have a kind that belongs in
a new API group, you should create that API group. In this case,
StorageClass looks like a natural fit with PersistentVolume and
PersistentVolumeClaim. I would expect a storage.k8s.io API group that
eventually contains all three, but could start with just the new one
StorageClass.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVPgqmuj7aLiIcly3UAXjzWW5tCbvks5qjyKHgaJpZM4JuI0k
.

[deads2k]

I think we need a systemic decision about this INCLUDING the "I want to add
a kind to an existing group that is at v1".

I don't see StorageClass as that case. If StorageClass were added to storage.k8s.io/v1, it would be that case. However, StorageClass was added to unrelated-group/v1beta1.

[smarterclayton]

Thinking about it, I'm not so sure that it has to be that way. There are certainly arguments that you can retcon an object into all prior versions, but objects themselves are fairly independent. If we had v2 PVC - they'd probably still bind to v1 PV. If they didn't, they're not really PVC anymore. Versions are for schema versioning. They don't map to fundamental behavior. Any change dramatic enough that you can't forward convert means it's not the same object anymore (RS VS RC).

[thockin]

Clayton: I don't know which item you are responding to David: I don't want to make a different decision because of instance-specific circumstances. The same decision was made for NetworkPolicy in v1.3 because it was being considered for the 'policy' apigroup but wasn't compatible with that groups version standing.

[lavalamp]

we need some serious SERIOUS streamlining

Been trying since before 1.3...

[thockin]

On Fri, Aug 26, 2016 at 2:09 PM, Daniel Smith notifications@github.com wrote:

we need some serious SERIOUS streamlining

Been trying since before 1.3...

Do not interpret as a slight, please. I know we're working on it. I
don't know what, if anything, we can do to make it go faster

[smarterclayton]

I think we need to reassess how we are putting objects into groups and how we version them. I don't think putting an alpha resource into a new group is wrong. Groups represent areas of function, not client contracts. Versions don't have to be atomic to the kinds within them. Groups can have permanent alpha versions for new resources. We don't have to add new resources to all old versions. The decisions about these need to be a bit broader than just a couple of folks talking, and we need to get a lot better at formalizing the process and applying it. I don't think we've succeeded at that yet.

[deads2k]

Groups can have permanent alpha versions for new resources.

That sounds reasonable. When combined with discovery and preferred version, it ought to be unambiguous when used.

[thockin]

I assume, and I think others do, that an apigroup with a given version
means that WHOLE API is versioned as such. Once foobar/v1alpha1 has been
EOL'ed, it would be surprising to see it come back to life but with a
different/new subset of Kinds.

Now that we have some miles on apigroups, I agree it is time to revisit.

On Fri, Aug 26, 2016 at 3:23 PM, Clayton Coleman notifications@github.com
wrote:

I think we need to reassess how we are putting objects into groups and
how we version them. I don't think putting an alpha resource into a
new group is wrong. Groups represent areas of function, not client
contracts. Versions don't have to be atomic to the kinds within them.
Groups can have permanent alpha versions for new resources. We don't
have to add new resources to all old versions.

The decisions about these need to be a bit broader than just a couple
of folks talking, and we need to get a lot better at formalizing the
process and applying it. I don't think we've succeeded at that yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVBhtAqdA36J2cmHsaiaZ-dXyq7HNks5qj2d5gaJpZM4JuI0k
.

[smarterclayton]

It might be surprising at first, but I'm not sure it's surprising enough to
jump through hoops in other areas.

You'd have a client like (import "k8s.io/client-go/storage/v1alpha1") and
call ("v1alpha1.StorageClass"). If StorageClass isn't there any more in a
new release, you'll figure it out. I think if we force ourselves to rev
major versions for everything in a group, we're going to a) cause ourselves
a bunch of trouble, and b) try to come up with reasons not to do "v2" (see
brian's minor versions suggestion)

I agree occasionally you'll be irritated to have to use "v2pods" and
"v1pods" at the same time... but you're already going to be using a bunch
of different clients just to do your day job ("extensions" and "storage"
and "apps" and "pods" etc). I'm not dead set on this particular path, but
I think it's worth questioning why all resources have to be updated at the
same time.

On Fri, Aug 26, 2016 at 7:40 PM, Tim Hockin notifications@github.com
wrote:

I assume, and I think others do, that an apigroup with a given version
means that WHOLE API is versioned as such. Once foobar/v1alpha1 has been
EOL'ed, it would be surprising to see it come back to life but with a
different/new subset of Kinds.

Now that we have some miles on apigroups, I agree it is time to revisit.

On Fri, Aug 26, 2016 at 3:23 PM, Clayton Coleman <notifications@github.com

wrote:

I think we need to reassess how we are putting objects into groups and
how we version them. I don't think putting an alpha resource into a
new group is wrong. Groups represent areas of function, not client
contracts. Versions don't have to be atomic to the kinds within them.
Groups can have permanent alpha versions for new resources. We don't
have to add new resources to all old versions.

The decisions about these need to be a bit broader than just a couple
of folks talking, and we need to get a lot better at formalizing the
process and applying it. I don't think we've succeeded at that yet.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-242866220>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AFVgVBhtAqdA36J2cmHsaiaZ-dXyq7HNks5qj2d5gaJpZM4JuI0k>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pydQVWGZb_LhyYQ6Pd7sAnhILbxLks5qj3lxgaJpZM4JuI0k
.

[bgrant0607]

I apologize that I don't have a lot of time for this discussion right now.

However, extensions is absolutely meant to be an incubator group, and using an incubator group is currently my preferred solution.

Yes, we could independently version every single resource, but that greatly complicates user experience, cross references between resources, defaulting of preferred API versions by clients and storage, and more. Groups and versions are intended to provide more cohesive API facets while still allowing some resources to evolve independently without rapidly churning through major API versions.

We could retcon less mature API groups, but that's extremely unintuitive for users IMO. We could put different subsets of resources into different versions of the same API group, but that has many of the same problems as independent versioning for each resource, and has some additional issues and would require extensions to our discovery API.

We could include Experimental, Alpha, or Beta in the names of new resources and just put them in more mature API groups, but that feels incongruous with the whole approach to versioning. I realize that we've discussed doing exactly this with fields.

The other option I've thought about recently is moving to semantic versioning and including minor versions in the API version, such as when adding new fields and new objects. To me, that would make the versions in the names of objects and fields both more workable, because we could apply our conversion machinery in future versions, and palatable, since it could be used in conjunction with the primary versioning scheme.

Part of our problem is self-inflicted, due to our rush to advance API groups before they are fully baked. If we weren't doing that, we could just keep groups in alpha or beta a little longer, add more resource types, and then promote them when the groups were actually ready. v1beta1 (which should have been alpha, but whatever) existed for over a year before we moved to v1beta3. How many of our post-v1 APIs did we put through more than one alpha or beta?

[deads2k]

However, extensions is absolutely meant to be an incubator group, and using an incubator group is currently my preferred solution.

It seems like this will result in a very busy API group with numerous, unrelated types in various stages of out-of-dateness. And that doing this will result in a nearly 100% chance that clients will have to change API groups to access the same resource as the API solidifies.

Are those characteristics intentional goals or are they side-effects because of the pain around creating new API groups?

[smarterclayton]

Agree that if extensions was v1alpha1 this would be an easier discussion. However, API groups have to be able to introduce and version types completely independently of each other - an OpenShift API object is not going to show up in extensions, and using it as a grab bag for core Kube resources I think is working against the goals for API groups to be independent chunks of function and to enable us to better firewall the implementations. scale, for instance, was a mistake. I think semantic versions on APIs can be harder for clients and for ourselves than some of the alternatives - agree that I want a way to flag a unique snapshot, but that has many of the same problems of per resource versions. I would want to discuss a practical example in more detail in a group setting before going further. I think I would argue that PV + PVC is a great example of two resources that would be in a group, and where the group version of the two are related. On the other hand, we are never going to be able to orchestrate a backward incompatible ObjectMeta change within the same version value (which is why the server cast proposal is needed), so we have to accept that version names across groups are unrelated. I think we need to give the API versioning discussions some more attention prior to 1.5. We have rushed multiple objects to early beta, put objects in the wrong group, and caused ourselves security problems along the way. I'd like to see a proposal we all agree on for promotion and a better process for agreeing something goes into a group. I also think we need to formalize API review a bit more - there's an increasing amount of changes and a lot more committers, and reviewers need to know these rules as well.

[smarterclayton]

On a related note to David question - Openshift is about to create 13 new API groups. If we need to make API group creation easier, we're going to do it. But if we can't even agree on what groups are for, we will be in trouble.

[pmorie]

I think there should be a clear rubric in writing that specifies exactly when/where to add an API group before this issue is closed.

[deads2k]

We discussed the pros and cons in sig-api-machinery yesterday. Choosing a particular group name means that clients (including our internal code) require less work and re-swizzling to handle promotions between versions. Even if you choose a group you end up not liking, the amount of work remains the same as the incubator work case.

opened #31886

[erictune]

Just saw this. For batch, we did rev to v2alpha1 when adding a kind (ScheduledJob) which was alpha, even though the other thing in the group was v1 (Job). If we hadn't done that:

• people would not have a signal that ScheduledJob was alpha.
• when the api group is enabled, an alpha-quality controller is enabled. that controller could go haywire and bring down the cluster.

We could move to a new model where we signal alpha differently (E.g. all the field names in the type or the Kind name starts with α, such as αScheduledJob. (see #30819). And we need some standard way to disable controllers that contain alpha code.

How can we decide these issues and then document them, before we add lots more groups?

[smarterclayton]

I'll note that doing that broke every bit of API machinery which wasn't adequately ready for it. So we also need to be sure we've fixed the underlying problems before we go everywhere else (@soltysh do you have follow up issues for your hacks there?)

[erictune]

Yes, v2alpha1 was not easy, so I'd love to have a different path that didn't involve more apiversions.

[thockin]

yeah, we need some huddle early in 1.5 to figure this out.

On Thu, Sep 8, 2016 at 10:59 AM, Eric Tune notifications@github.com wrote:

Closed #31521 #31521.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVJZO7Rt6HcQk9Arr431RBMXzYLhXks5qoE0FgaJpZM4JuI0k
.

[lavalamp]

batch/v2alpha1 was a trailblazer. The trail should be easier for others now
that it's been blazed.

We did discuss in the last api machinery sig dropping the requirement that
each version has a complete set of resources. This would require us to
figure out how to make multiple versions available in our clients, but
probably otherwise would be more intuitive for people.

On Thu, Sep 8, 2016 at 11:25 AM, Tim Hockin notifications@github.com
wrote:

yeah, we need some huddle early in 1.5 to figure this out.

On Thu, Sep 8, 2016 at 10:59 AM, Eric Tune notifications@github.com
wrote:

Closed #31521 #31521.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVJZO7Rt6HcQk9Arr431RBMXzYLhXks5qoE0FgaJpZM4JuI0k>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglooW0o3CfA4XhPDDkc1idpYuHgozks5qoFMqgaJpZM4JuI0k
.

[thockin]

I don't think that is more intuitive. If these are "api groups" I would
expect the whole thing to rev at the same time. If we're going to rev
different types independently, then the GROUP does not actually have a
version at all, EACH KIND does. That may be OK, but it is a tradeoff we
should make consciously.

On Thu, Sep 8, 2016 at 11:29 AM, Daniel Smith notifications@github.com
wrote:

batch/v2alpha1 was a trailblazer. The trail should be easier for others now
that it's been blazed.

We did discuss in the last api machinery sig dropping the requirement that
each version has a complete set of resources. This would require us to
figure out how to make multiple versions available in our clients, but
probably otherwise would be more intuitive for people.

On Thu, Sep 8, 2016 at 11:25 AM, Tim Hockin notifications@github.com
wrote:

yeah, we need some huddle early in 1.5 to figure this out.

On Thu, Sep 8, 2016 at 10:59 AM, Eric Tune notifications@github.com
wrote:

Closed #31521 #31521.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#31521 (comment)
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVJZO7Rt6HcQk9Arr431RBMXzYLhXks5qoE0FgaJpZM4JuI0k>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245692385>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglooW0o3CfA4XhPDDkc1idpYuHgozks5qoFMqgaJpZM4JuI0k>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVFLqyBEwF26z8QIzwpew7HmnQtGPks5qoFQbgaJpZM4JuI0k
.

[smarterclayton]

Technically each kind already has its own version because we change them at
different rates. We don't really want a proliferation of versions though,
so your core point stands.

On Thu, Sep 8, 2016 at 2:32 PM, Tim Hockin notifications@github.com wrote:

I don't think that is more intuitive. If these are "api groups" I would
expect the whole thing to rev at the same time. If we're going to rev
different types independently, then the GROUP does not actually have a
version at all, EACH KIND does. That may be OK, but it is a tradeoff we
should make consciously.

On Thu, Sep 8, 2016 at 11:29 AM, Daniel Smith notifications@github.com
wrote:

batch/v2alpha1 was a trailblazer. The trail should be easier for others
now
that it's been blazed.

We did discuss in the last api machinery sig dropping the requirement
that
each version has a complete set of resources. This would require us to
figure out how to make multiple versions available in our clients, but
probably otherwise would be more intuitive for people.

On Thu, Sep 8, 2016 at 11:25 AM, Tim Hockin notifications@github.com
wrote:

yeah, we need some huddle early in 1.5 to figure this out.

On Thu, Sep 8, 2016 at 10:59 AM, Eric Tune notifications@github.com
wrote:

Closed #31521 <#31521
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#event-782803350
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVJZO7Rt6HcQk9Arr431RBMXzYLhXks5qoE0FgaJpZM4JuI0k>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245692385>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglooW0o3CfA4XhPDDkc1idpYuHgozks5qoFMqgaJpZM4JuI0k>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245693364>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVFLqyBEwF26z8QIzwpew7HmnQtGPks5qoFQbgaJpZM4JuI0k>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p9V2ObD26EZD-l9STu-AnG6U6OD7ks5qoFTRgaJpZM4JuI0k
.

[lavalamp]

Specifically we were talking about having a sort of rotating alpha group
instead of bumping the entire group's version every time we graduate a
resource from alpha.

On Thu, Sep 8, 2016 at 12:31 PM, Clayton Coleman notifications@github.com
wrote:

Technically each kind already has its own version because we change them at
different rates. We don't really want a proliferation of versions though,
so your core point stands.

On Thu, Sep 8, 2016 at 2:32 PM, Tim Hockin notifications@github.com
wrote:

I don't think that is more intuitive. If these are "api groups" I would
expect the whole thing to rev at the same time. If we're going to rev
different types independently, then the GROUP does not actually have a
version at all, EACH KIND does. That may be OK, but it is a tradeoff we
should make consciously.

On Thu, Sep 8, 2016 at 11:29 AM, Daniel Smith notifications@github.com
wrote:

batch/v2alpha1 was a trailblazer. The trail should be easier for others
now
that it's been blazed.

We did discuss in the last api machinery sig dropping the requirement
that
each version has a complete set of resources. This would require us to
figure out how to make multiple versions available in our clients, but
probably otherwise would be more intuitive for people.

On Thu, Sep 8, 2016 at 11:25 AM, Tim Hockin notifications@github.com
wrote:

yeah, we need some huddle early in 1.5 to figure this out.

On Thu, Sep 8, 2016 at 10:59 AM, Eric Tune <notifications@github.com

wrote:

Closed #31521 <https://github.com/kubernetes/kubernetes/issues/
31521
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#event-782803350
,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVJZO7Rt6HcQk9Arr431RBMXzYLhXks5qoE0FgaJpZM4JuI0k>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245692385>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAnglooW0o3CfA4XhPDDkc1idpYuHgozks5qoFMqgaJpZM4JuI0k>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245693364>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AFVgVFLqyBEwF26z8QIzwpew7HmnQtGPks5qoFQbgaJpZM4JuI0k>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/kubernetes/issues/
31521#issuecomment-245694531>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ABG_p9V2ObD26EZD-l9STu-AnG6U6OD7ks5qoFTRgaJpZM4JuI0k>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglraphtRhhSekQ1F4vc-rsnUEHwYzks5qoGKtgaJpZM4JuI0k
.

[deads2k]

Specifically we were talking about having a sort of rotating alpha group
instead of bumping the entire group's version every time we graduate a
resource from alpha.

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.

[soltysh]

@soltysh do you have follow up issues for your hacks there?

Yeah, quite a few of them are on my list, just earlier today I hit dynamic client not working properly with batch/v2alpha1.

Specifically we were talking about having a sort of rotating alpha group instead of bumping the entire group's version every time we graduate a resource from alpha.

Since batch is the trail blazer here, I'd say continue to evaluate options on it, since with the 'maturity' it's easier to spot what's broken when changing and not only after. Should I read it that instead of batch/v2alpha1 we should just have batch/alpha? What will happen with extensions/v1beta1 the resources available there should also migrate either directly to destination groups (gradually) and the group itself should be renamed to extensions/alpha, right?

[deads2k]

Should I read it that instead of batch/v2alpha1 we should just have batch/alpha?

I don't think we have a firm decision yet. Sparse versions have maintenance merit, but there are reasonable arguments against them too.

[goltermann]

Moving out of v1.4 as this is a P2.

[thockin]

Do we want to repurpose this as "discuss apigroup versioning" ?

[smarterclayton]

Yes

On Sep 15, 2016, at 1:45 AM, Tim Hockin notifications@github.com wrote:

Do we want to repurpose this as "discuss apigroup versioning" ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31521 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p3AajDUTCU-Xnp9kmIp6vEB-Um2mks5qqNuIgaJpZM4JuI0k
.

[dims]

This needs to be triaged as a release-blocker or not for 1.5 @deads2k @smarterclayton @lavalamp

[deads2k]

already fixed