Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

@markturansky How sophisticated do you imagine the selectors will need to be? I didn't see example use cases in the proposal.

If you haven't seen it, a slightly more powerful selector was designed for nodes:
https://github.com/kubernetes/kubernetes/blob/master/docs/design/nodeaffinity.md

cc @davidopp

@bgrant0607 I'm happy to follow whatever model for selectors is desired for the API. Are any of these new selectors genericized at all? Implementing my own persistentVolumeOperator, for example, seems gratuitous.

@markturansky The label selector you used is here:
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/unversioned/types.go#L403

Thanks @bgrant0607. Much easier with the generic unversioned.LabelSelector. PR is updated.

PR needs rebase

It makes the swagger a bit ugly, but that's ok. If we need to, we can switch to another copy of the LabelSelector types in the future, but this is the first usage in v1 at the moment.

All of the comments in the PV*types incorrectly refer to Go field names, but let's fix that separately.

LGTM. Please rebase.

@bgrant0607 I see what you mean regarding the type names being in the comments in the PV types. I can follow up with that PR.

LGTM fwiw

@k8s-bot test this issue: #IGNORE

Tests have been pending for 24 hours

@k8s-bot test this please github issue: #IGNORE (the previous build is handing for 20+ hours)

@k8s-bot test this please github issue: #IGNORE (the previous build is handing for 20+ hours)

@ixdy @spxtr - it seems than Jenkins is not picking up this PR. Can you please take a look?

@k8s-bot test this issue: #IGNORE

Tests have been pending for 24 hours

We're tracking this for OpenShift - any objections to adding the v1.2 milestone to this PR? @thockin @bgrant0607 @mikedanese @davidopp

Actually, if there isn't any code going in to 1.2 that's going to use this API change, I would vote to move it to 1.3

Actually, if there isn't any code going in to 1.2 that's going to use this API change, I would vote to move it to 1.3

I'll let @bgrant0607 make the call since he is the keeper of the API.

My 2 cents: This only exposes new API options but doesn't actually enable the functionality using it--that could be confusing for the user. We should merge this into the same release as the feature(s) that intend to use it: storage classes and volume label selection. Both of those features will not be part of 1.2, and we do not release features in minor releases (i.e. 1.2.X), so they will likely be part of 1.3. Therefore, I'd say hold off on merging this for 1.2.

Yeah, 1.3 is fine with us - sorry for the noise 😄

Do we need to temporarily remove the lgtm label so it doesn't get merged by the bot before the 1.2 branch is cut?

I agree with @saad-ali . Removed LGTM label.

1.3 SGTM.

1.2 will be cut on Friday.

@markturansky PR needs rebase

GCE e2e build/test passed for commit 4910f99.

• Build Log
• Test Artifacts
• Internal Jenkins Results

@markturansky PR needs rebase

Closed in favor of #25298 by @pmorie