Change:
"k8s.io/kubernetes/pkg/api/unversioned" client "k8s.io/kubernetes/pkg/client/unversioned" "k8s.io/kubernetes/pkg/util/sets" <del> "k8s.io/kubernetes/pkg/util/system" </del> "k8s.io/kubernetes/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Create a pod: the pod is always , and describes as: kubelet log: Deny the pod orchestration with duplicate volumes, OR the pod can be running successfully. Create a pod with the duplicate pvc as above. Root cause The key of persistent volume info in DSW is named after, and the is a : When getting the unmounted volumes, it uses : In our case, volume will corve the volume in DSW, and the volume info is lost in ASW. Solution: 2 choices: Consider it as an invalid request, and deny creating it. Construct uniqueVolumeName with when the volume is a persistent volume.Kubernetes version (use ): v1.20.4 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig apps /sig node /sig storage
I don't think it's common sense to write duplicate volumes, and people don't use them that way, but if you want to achieve the above YAML intent, you can do it this way so I think it might be better this way if write duplicate volumes
/assign
I recognize your point, but I think kubernetes should validate that.
Yes, I think verification should be as well I'll try to do that
Then I thought about it again, and I think this YAML might sometimes be used this way So it may not be a good idea to say no outright Can you give me some advice ?
, I think that it is possible in some situations that a pod is running with duplicate persistent volume. For example, a container running web application reads application data from a persistent volume and saves logs to another PV.
This seems possible and Thank you for your description of the situation.
Does this address your use case?

I've tried it and it works But does this duplicate PV need to take certain measures, verification failed or can be successful or other pod Always in the phase
/unassign
This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /remove-kind bug /kind support /triage accepted /priority backlog /area documentation /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /kind support /triage accepted /priority backlog /area documentation /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : This is more a support request rather than a bug... however I am not closing it since it would be good to document this solution: /kind support /triage accepted /priority backlog /area documentation /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hey I am new to open source and will like to contribute to this project can you guide me on what needs to done.
Welcome ! Sure, so the goal is to document that example of a double mount of the same pv. I would put it somewhere here: Which corresponds to this repo:
If you have another idea about the best page to document it, please make it as you think.
are you taking this up , or should i take?
yes, I am taking this up.
/remove-kind support /kind documentation
Ah documentation is a kind... Makes sense. Thx Elana!
Hii after reading docs . I think the example of " double mount of the same PV " needs to be either before or at the end of the page. what did you say? And it may look something like this.

Running pods with the duplicate persistent volume, Example: A container running a web application reads application data from a persistent volume and saves logs to another PV. as the example was mentioned by
Thanks for looking at it. I wonder if that example would nicely add to as it's more hands on than the other page. What do you think?
yeah, docs seems the right place to add the " double mount of the same PV" example. and I think It should be after the . What do you think?
Yes, so now sign the CLA, open a PR and link this issue. We'll see what they say during the review...
I open a PR but still it is not reviewed. Do I need to assign it to someone?
I see your PR and prow has requested review from 2 reviewers... Let's give them one or two days and then we can poke them again
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
cc
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]: