[manila-csi-plugin] make auth more tolerant

[mandre]

What this PR does / why we need it: Remove dependency on a couple of fields where the logic was wrong. For example, these fields do not necessarily depend on a password being set, as we could be using application credentials.

This prevents manila driver from entering an error state when it finds unnecessary fields in the clouds.yaml. It now simply ignores them.

Which issue this PR fixes(if applicable):

Fixes #2757

Special notes for reviewers: The fix is in pkg/client/client.go so presumably affects all binaries?

Release note:

Make authentication more tolerant to unneeded fields

[kayrus]

I never had issues with application credentials and manila CSI. Are you sure this is not related to a cloud.yaml parser code?

[mandre]

@kayrus I have provided more context in the related issue. You'll get an error when using application credentials, and leaving username in the auth options. One could argue that the clouds.yaml is invalid and should then be rejected, but openstack SDK and other components in kubernetes happily takes it and ignores the extra options. The fact that the manila driver errors on clouds.yaml is a surprising behavior IMO. I propose to loosen some validations and make the auth parsing more tolerant.

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle rotten

[gouthampacha]

/remove-lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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 PR is closed

You can:

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

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

/lifecycle stale

[gouthampacha]

/remove-lifecycle stale

[stephenfin]

I stumbled into this today and can confirm it's a real issue (I think it was the same root cause also: I had an errant username field set with application credentials).

We will get good error messages from gophercloud if it's unable to authenticate due to missing fields, so I don't think we lose anything here. I think we should get this in.

/approve /lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stephenfin

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~~ [stephenfin]

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