Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

@k8s-bot test this: issue #28285

Given the state of the 1.4 release can we really justify this move? I am fine with it FOR THIS CASE, though I really do want to get some consensus on the more complex case of adding a beta type in a non-beta group, vs a catch-all incubator group.

@pwittrock

@bgrant0607 FYI

@lavalamp @thockin @pmorie @kubernetes/sig-storage I've gotten all the bits re-swizzled to move StorageClass to a storage group. I'd really like to get this in 1.4 so that we can do a straight move instead of a migration. ptal.

To the best of my knowledge, this change is completely blind-siding @kubernetes/sig-storage. I would have liked to have seen (or if there was one, been made aware of) a proposal for this change. I'd like the storage SIG to have an opportunity to discuss/review this before there are any plans of merging this PR

To the best of my knowledge, this change is completely blind-siding @kubernetes/sig-storage. I would have liked to have seen (or if there was one, been made aware of) a proposal for this change.

Sorry, it was discussed here #29694 (comment) (original pull) and here #31521 (issue opened) with tags for the original author and the active reviewers on that pull for the types.

Steve, That's reasonable, though I don't expect any concern - it's purely
about naming.

On Fri, Sep 2, 2016 at 8:09 AM, Steve Watt notifications@github.com wrote:

To the best of my knowledge, this change is completely blind-siding
@kubernetes/sig-storage
https://github.com/orgs/kubernetes/teams/sig-storage. I would have
liked to have seen (or if there was one, been made aware of) a proposal for
this change. I'd like the storage SIG to have an opportunity to
discuss/review this before there are any plans of merging this PR

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

@deads2k you have to update the examples
https://github.com/kubernetes/kubernetes/tree/master/examples/experimental/persistent-volume-provisioning

I think naming is important. These terms we choose carry a lot of context with them. It takes time for these terms and the context behind them to diffuse within our community and users. I'm sensitive about Storage Classes specifically because its not particularly well understood yet.

The Storage SIG has started thinking about naming (we discussed this at the Storage F2F) and one of the outcomes has been #30474. I think @jingxu97 hasn't seen much activity on that yet, because its lower priority than closing out Kube 1.4

OK folks, I'm reverting my objections. For reference, I misinterpreted this PR as renaming the StorageClass API Object, which is not what is being proposed.

Change matches my expectations of the original discussion

So the release justification for 1.4 is that this is a net new resource (no broken backwards users) and this is a signature 1.4 feature that we want to ensure reduces significant long term maintenance costs on. So even though this increases 1.4 risk, it is our last chance to avoid significant future work.

@pwittrock FYI for release process and exception process. I don't have the handy list of the exception questions so I tried to handle them above.

+1 to this refactor for 1.4

@pmorie can you walk me through/send me a link to any special process I need to follow for 1.4 picks?

@deads2k I'll walk you through in meatspace if you need it, cherry-pick doc is at: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/cherry-picks.md

You don't need anything special if this merges before we do a fast-forward.

GCE e2e build/test passed for commit 6320dc6.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit 6320dc6.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

This PR broke gke-slow suite, concretely this test:
#32185

@k8s-oncall - FYI

@smarterclayton @lavalamp Can you make sure the test break gets resolved. I do not plan to cherrypick this until then.

The test break was 'fixed' in #32199
So these can/should be picked together. Once GKE is fixed we can decide if we want to pick #32200

@eparis Thanks

Actually, @pwittrock, there's a chicken and egg problem here. Until this api group exists in 1.4, we can't cleanly turn it on in GKE. This change needs to be cherrypicked first.

@jlowdermilk This will be cherrypicked into 1.4 shortly.

Commit found in the "release-1.4" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked.