New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update default storageclasses to use delayed binding #69642

Open
msau42 opened this Issue Oct 10, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@msau42
Member

msau42 commented Oct 10, 2018

Is this a BUG REPORT or FEATURE REQUEST?:
@kubernetes/sig-storage-feature-requests

What happened:
Once topology goes GA, let's update the default storageclasses to set "WaitForFirstConsumer" volume binding mode. The addon is set to "EnsureExists", which means that if the object is already created, then we do not modify it. So users upgrading will not be affected. Only new clusters created will get the new default storageclass. This will need an "ACTION REQUIRED" release note that users need to update their workflow if they were dependent on the PVC being provisioned first before creating Pods.

@msau42

This comment has been minimized.

Show comment
Hide comment
@msau42

msau42 Oct 10, 2018

Member

/assign

Member

msau42 commented Oct 10, 2018

/assign

@msau42

This comment has been minimized.

Show comment
Hide comment
@msau42

msau42 Oct 10, 2018

Member

This has the potential to break e2e and upgrade tests

Member

msau42 commented Oct 10, 2018

This has the potential to break e2e and upgrade tests

@msau42

This comment has been minimized.

Show comment
Hide comment
@msau42

msau42 Oct 10, 2018

Member

actually it should not break upgrade because of EnsureExists. Need to double check downgrade case

Member

msau42 commented Oct 10, 2018

actually it should not break upgrade because of EnsureExists. Need to double check downgrade case

@msau42

This comment has been minimized.

Show comment
Hide comment
@msau42
Member

msau42 commented Oct 10, 2018

@ddebroy

This comment has been minimized.

Show comment
Hide comment
@ddebroy

ddebroy Oct 13, 2018

Member

This sounds great! Do you think at some point after this, perhaps 1.15, the default for volume binding mode may also be switched to "WaitForFirstConsumer"?

Member

ddebroy commented Oct 13, 2018

This sounds great! Do you think at some point after this, perhaps 1.15, the default for volume binding mode may also be switched to "WaitForFirstConsumer"?

@msau42

This comment has been minimized.

Show comment
Hide comment
@msau42

msau42 Oct 13, 2018

Member

since volume binding mode is an API field, I do not think we can change API defaults until we move to a new API version.

Member

msau42 commented Oct 13, 2018

since volume binding mode is an API field, I do not think we can change API defaults until we move to a new API version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment