-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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.
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
CSI: per_alloc volumes have wrong link in alloc task table #11965
Comments
Hacky branch for discussion here: https://github.com/hashicorp/nomad/compare/b-ui-csi-incorrect-link-for-per-alloc |
Did some digging with @ChaiWithJai
there are two ways we could solve this:
Because of how many places we'd have to make that store request in the former option, I'm going to advocate for the latter. I'll have a look at the response schema shortly. |
The problem here is that the API doesn't know the volume name, as the volume request is part of a task group and not an allocation. Including the name would imply that the output of We're effectively running into the same problem with the first two bullet-points, which is that we're looking at the task group and not the allocation. |
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
In #11896 we moved the link target for CSI volumes on the allocation detail page to use the
source
field as the target for the URL. But for volumes withper_alloc = true
, this doesn't work because the source does not include the allocation index:For example, this link should be to
webdata[0]
because it's the 0th alloc:Because this data is written to the job and not to the individual allocations in the state store, we'd have to modify the state on the fly to make it the "correct" value in the API, but that would make the job definition in this API vary depending on which allocation we look at. So we should have this bit of logic in the UI add the allocation index, just as we do in the client when we consume this value.
Note that we haven't yet shipped this bug in a release, so it'd be nice for us to get to as part of the 1.3.0 work. I can probably take this one on while doing other CSI cleanup.
The text was updated successfully, but these errors were encountered: