subset of supported topology keys are not working for waitforfirstconsumer

[pawanpraka1]

What type of PR is this?
/kind feature

What this PR does / why we need it:

fixes:- #420

If waitforfirstconsumer is used and if the driver supports multiple topology keys,
mentioning single key(or less than supported keys) in the storageclass is not working.
The csi-provisioner gets list of all the topology keys from the csinode object
and gets the values for those keys from the node object. Now this key-value term
is matched against the topology mentioned in the storageclass and it should match
entirely which is not correct as even if topology mentioned in the storageclass
is subset of the key-value term supported by the driver, then the node is a valid condidate.

Instead of strictly checking for the equality of the selected node's topology with
the allowedTopologies mentioned in the storageclass, we should check if allowedTopologies
is subset of selected node's topology.

Does this PR introduce a user-facing change?:

We can now provide few keys in the allowedtopologies of all the keys supported by the driver in late binding case.

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

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. I understand the commands that are listed here.

[k8s-ci-robot]

Welcome @pawanpraka1!

It looks like this is your first PR to kubernetes-csi/external-provisioner 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-csi/external-provisioner has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @pawanpraka1. Thanks for your PR.

I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[pawanpraka1]

I signed it

[pawanpraka1]

I signed it

[pawanpraka1]

I signed it

[pawanpraka1]

I signed it

[msau42]

/ok-to-test
/assign @verult

[pawanpraka1]

/assign @msau42

[msau42]

/assign @pohly

[k8s-ci-robot]

@pawanpraka1: The label(s) kind/documentatinon cannot be applied, because the repository doesn't have them

In response to this:

What type of PR is this?
/kind bug
/kind documentation

What this PR does / why we need it:

fixes:- #420

If waitforfirstconsumer is used and if the driver supports multiple topology keys,
mentioning single key(or less than supported keys) in the storageclass is not working.
The csi-provisioner gets list of all the topology keys from the csinode object
and gets the values for those keys from the node object. Now this key-value term
is matched against the topology mentioned in the storageclass and it should match
entirely which is not correct as even if topology mentioned in the storageclass
is subset of the key-value term supported by the driver, then the node is a valid condidate.

Instead of strictly checking for the equality of the selected node's topology with
the allowedTopologies mentioned in the storageclass, we should check if allowedTopologies
is subset of selected node's topology.

Special notes for your reviewer:

Does this PR introduce a user-facing change?:
/kind documentatinon
When we are using few keys of all the supported keys by the driver in the storageclass allowedtopologies, the volume provisioning was failing. There was a bug in matching the allowedtopologies mentioned in the storageclass with the topologies supported by the driver. It was assuming all the keys supported by the driver to be present in the allowed topologies. Fixed this relaxing this assumption.

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.

[pawanpraka1]

Can you also add a release note for this?

done @msau42 .

[msau42]

/kind feature
/remove-kind documentation

[msau42]

/lgtm
/approve
Thanks for working on this!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: msau42, pawanpraka1

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [msau42]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pawanpraka1]

@msau42 travis has passed but status has not updated yet, Please check.

[msau42]

Can you try force pushing your branch again? I'm not sure why travis reporting is stuck

[pawanpraka1]

/retest

[pawanpraka1]

@msau42 can you restart the travis build?

[msau42]

I'm not able to restart it, I think it is triggered based on git pushes. Maybe try squashsing your commits and then force pushing?

[pawanpraka1]

@msau42 done, forced push the changes.

[msau42]

/lgtm

[pawanpraka1]

@msau42 same issue, again.

[msau42]

I will just force merge the PR, all the other checks have passed. Thanks!

[pawanpraka1]

thanks @msau42 .