If multiple default StorageClasses exist, pvc request fails

[screeley44]

Do we want to stop the creation of a StorageClass with the "is-default" annotation, if one already exists on the cluster?

If I create multiple "default" storage classes

[root@screeley-sc1 gce]# kubectl get storageclass
NAME            TYPE                   ISDEFAULT
another-class   kubernetes.io/gce-pd   NO        
generic1-slow   kubernetes.io/gce-pd   YES       
generic2-fast   kubernetes.io/gce-pd   YES       

and then try to submit a PVC, I get this error

[root@screeley-sc1 gce]# kubectl create -f gce-pvc-multidefault.yaml 
Error from server (Forbidden): error when creating "gce-pvc-multidefault.yaml": persistentvolumeclaims "pvc-default" is forbidden: Internal error occurred: 2 default StorageClasses were found

@kubernetes/sig-storage

[screeley44]

@saad-ali - any thoughts on this? Do we want to not allow this to happen?

[jsafrane]

@kubernetes/sig-storage-misc, shall we update our admission controller to prevent two classes to be marked as default at the same time?

[msau42]

Sounds reasonable to me

[thockin]

This is something of scope creep on the admission controller - now it handles PVCs and StorageClasses. If we do this, make sure to handle Update properly. This seems to be a backdoor way to get around the "no cross object validation" pseudo-rule. @lavalamp any other precedents around "only one" situations?

…

On Tue, Jan 10, 2017 at 9:44 AM, Michelle Au ***@***.***> wrote: Sounds reasonable to me — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#34549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVHBUUpcqG0x_I0jcQVJjJL5NzN7Tks5rQ8NrgaJpZM4KTy-A> .

[lavalamp]

@smarterclayton is working on a proposal to move admission controllers out of process, which we talked about a lot during today's API Machinery SIG.

If you really want to provide a guarantee like this, you need some sort of locking mechanism around the check. The naive implementation where the admission controller lists all storageclasses and checks for uniqueness is actually quite broken (I'll leave this as an exercise for the reader), possibly worse than not doing the check at all because other components won't realize they have to handle the case where two get in.

I would consider making the controller implementing this thing responsible for demoting one class if it finds two defaults. This is the model that we use for Kubelet to reject a pod if it actually doesn't fit. I'm personally more of a fan of this approach because it means the cluster state is eventually correct. If the only defense against invalid state is an admission control check, then a bug there is potentially disastrous since the system can't self-heal. Of course if there's no bugs then it's probably not a problem...

[msau42]

My only concern about making it out of process is that it's not as easy to notify the user that they made a mistake. By automatically demoting classes, then the user may not realize that their volume is not using their intended default class since the provisioning will succeed with a different default class.

[thockin]

yeah, I'd rather continue to error, I think

…

On Wed, Jan 18, 2017 at 2:24 PM, Michelle Au ***@***.***> wrote: My only concern about making it out of process is that it's not as easy to notify the user that they made a mistake. By automatically demoting classes, then the user may not realize that their volume is not using their intended default class since the provisioning will succeed with a different default class. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#34549 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVPJW9_YL9bh8MqOY9Dlvtf_gwJAbks5rTpEQgaJpZM4KTy-A> .

[msau42]

/sig storage

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[ashishranjan738]

/reopen

[k8s-ci-robot]

@ashishranjan738: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[j-griffith]

/reopen

[k8s-ci-robot]

@j-griffith: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[yashbhutwala]

/remove-lifecycle rotten

[yashbhutwala]

/reopen

[k8s-ci-robot]

@screeley44: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[immae1]

/remove-lifecycle stale
still there the issue...

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[altitude1326]

The bug still exists need to re-open it.

/reopen

[k8s-ci-robot]

@altitude1326: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

The bug still exists need to re-open it.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[altitude1326]

@msau42 can you do somthing for reopen and treat this bug please ?

[QJoly]

the problem is still here

[lavalamp]

/reopen
/lifecycle frozen
/uncc

[k8s-ci-robot]

@lavalamp: Reopened this issue.

In response to this:

/reopen
/lifecycle frozen
/uncc

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jsafrane]

This should be fixed by #110559

[khteh]

Still happen!

[aojea]

Still happen!

in 1.26?

[khteh]

Due to them being annotated as default. There can only be ONE default sc.

[xing-yang]

This should be fixed now by the RetroActive Default Storage Class feature.

[xing-yang]

/close

[k8s-ci-robot]

@xing-yang: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.