Skip to content
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.

Sign up for GitHub

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

Jump to bottom

The Azure NetApp Files Backend should not report "online" upon receiving invalid credentials. #465

Closed
carlosonunez opened this issue Oct 19, 2020 · 3 comments · May be fixed by #466
Closed

The Azure NetApp Files Backend should not report "online" upon receiving invalid credentials. #465

carlosonunez opened this issue Oct 19, 2020 · 3 comments · May be fixed by #466
Labels
enhancement

Comments

@carlosonunez
Copy link

Describe the solution you'd like
As of v20.04, the Azure NetApp Files backend will report itself as being online even if its backend.json contains invalid credentials. The backend should report itself as being offline or failed in this scenario.

Describe alternatives you've considered
The current workaround is to initialize the backend with tridentctl create backend and then attempt to provision a volume through a PersistentVolumeClaim or wait for capacity pool discovery to take place.

Additional context
Add any other context or screenshots about the feature request here.

I'm working on a pull request that addresses this. Fork is at github.com/carlosonunez/trident. A link to the pull request will be submitted in the comments!
carlosonunez pushed a commit to carlosonunez/trident that referenced this issue Oct 19, 2020
Verify Azure API works before enabling ANF backend
c1b9081 
Fixes [issue NetApp#465](NetApp#465)

**Describe the solution you'd like**
As of v20.04, the Azure NetApp Files backend will report itself as being `online` even if its `backend.json` contains invalid credentials. The backend should report itself as being `offline` or `failed` in this scenario.

**Describe alternatives you've considered**
The current workaround is to initialize the backend with `tridentctl create backend` and then attempt to provision a volume through a `PersistentVolumeClaim` or wait for capacity pool discovery to take place.
carlosonunez pushed a commit to carlosonunez/trident that referenced this issue Oct 19, 2020
Verify Azure API works before enabling ANF backend
d2cb02d 
Fixes [issue NetApp#465](NetApp#465)

**Describe the solution you'd like**
As of v20.04, the Azure NetApp Files backend will report itself as being `online` even if its `backend.json` contains invalid credentials. The backend should report itself as being `offline` or `failed` in this scenario.

**Describe alternatives you've considered**
The current workaround is to initialize the backend with `tridentctl create backend` and then attempt to provision a volume through a `PersistentVolumeClaim` or wait for capacity pool discovery to take place.
@carlosonunez carlosonunez mentioned this issue Oct 19, 2020
Open
netapp-ci pushed a commit that referenced this issue May 10, 2021
@ntap-rippy
Retry and attempt to fix volume creations that encounter HTTP 422 err…
d67e036 
…ors (#465)
@balaramesh
Copy link
Contributor

@carlosonunez can I ask you to clarify what "invalid credentials" means here? The reason I ask this is: ANF backends need 4 parameters to identify the ANF subscription that it needs to provision vols against: clientID, subscriptionID, tenantID, and clientSecret. If the parameters have an incorrect/false value provided in the backend definition, Trident will be able to catch that since calls to the Azure SDK will fail. Please correct me if I am wrong here.

Based on what was explained above, it looks like the real problem would be the access permissions for the app registration (whose credentials are passed with clientID, clientSecret). It could be that an app registration with insufficient permissions leads to a backend being created successfully, but it really doesn't have the ability to fetch virtual networks/capacity pools for example. The Trident logs will contain references to that. For example, "No Capacity Pools Found".

Can you share the error message you observed when you tried to create a PVC on a backend that was reported online?

@carlosonunez
Copy link
Author

@balaramesh , thanks for getting back to me. What I mean by the PR here is that I should see that I have invalid credentials or some other issue authenticating into Azure before I attempt to create a backend with tridentctl. While you are correct in that one will eventually see vols fail to get created due to HTTP 401s or HTTP 403s in the chain, it's not immediately obvious when this happens. In my case, it lead to a confusing user experience.

Unfortunately I no longer have a screenshot of the error that I received, as I'm no longer working with the client using this provisioner. However, I did raise an issue with NetApp support at the time and referenced this issue and the pull request associated with it in that ticket. You might have better luck searching for the originating error internally.

I hope that helps!

@gnarl
Copy link
Contributor

gnarl commented Jan 21, 2022

This issue is fixed with commit 809f0d4 and will be included in the Trident 22.01 release. The ANF storage driver will discover if the backend credentials are invalid during driver initialization.

@gnarl gnarl closed this as completed Jan 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Verify Azure API works before enabling ANF backend carlosonunez/trident
3 participants
@gnarl @carlosonunez @balaramesh