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.

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/api: populate ReadAllocs/WriteAllocs fields #9377

Merged
merged 2 commits into from
Nov 25, 2020

Conversation

tgross
Copy link
Member

@tgross tgross commented Nov 17, 2020

Fixes #9215

The API is missing values for ReadAllocs and WriteAllocs fields, resulting
in allocation claims not being populated in the web UI. These fields mirror
the fields in nomad/structs.CSIVolume. Returning a separate list of stubs
for read and write would be ideal, but this can't be done without either
bloating the API response with repeated full Allocation data, or causing a
panic in previous versions of the CLI.

The nomad/structs fields are persisted with nil values and are populated
during RPC, so we'll do the same in the HTTP API and populate the ReadAllocs
and WriteAllocs fields with a map of allocation IDs, but with null
values. The web UI will then create its ReadAllocations and
WriteAllocations fields by mapping from those IDs to the values in
Allocations, instead of flattening the map into a list.


I've tested this out via the web UI and verified nomad volume status, nomad alloc status, and nomad node status aren't broken, including with a v0.12.8 version of the command line.

hash.ReadAllocations = Object.keys(readAllocs).map(bindIDToAlloc(readAllocs));
hash.WriteAllocations = Object.keys(writeAllocs).map(bindIDToAlloc(writeAllocs));
hash.ReadAllocations = Object.keys(readAllocs).map(bindIDToAlloc(hash.Allocations));
hash.WriteAllocations = Object.keys(writeAllocs).map(bindIDToAlloc(hash.Allocations));
Copy link
Member Author

@tgross tgross Nov 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for reviewers: would it save browser memory if we nulled-out the hash.Allocations, hash.ReadAllocs and hash.WriteAllocs fields after we're done with them here? Or is this object so ephemeral that it's meaningless to do so?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know off the top of my head if hash sticks around or if a copy is what gets inserted into the store. It wouldn't hurt to add a delete hash.Allocations just to err on the side of caution.

@github-actions
Copy link

github-actions bot commented Nov 17, 2020

Ember Asset Size action

As of efdce68

Files that got Bigger 🚨:

File raw gzip
nomad-ui.js +50 B +8 B

Files that stayed the same size 🤷‍:

File raw gzip
vendor.js 0 B 0 B
nomad-ui.css 0 B 0 B
vendor.css 0 B 0 B

@github-actions
Copy link

github-actions bot commented Nov 17, 2020

Ember Test Audit comparison

master efdce68 change
passes 1536 1536 0
failures 0 0 0
flaky 0 0 0
duration 7m 40s 364ms 8m 06s 396ms +26s 032ms

Copy link
Contributor

@notnoop notnoop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The golang side is LGTM.


// WriteAllocs is a map of allocation IDs for tracking writer claim
// status. The Allocation value will always be nil; clients can populate
// this data by iterating over the Allocations field.
WriteAllocs map[string]*Allocation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why we chose this representation? If the map value is never a populated alloc, how does it compare to using map[string]bool (explicitly meaningless value) or a plain slice []string (avoid value but losing uniqueness)? Not advocating for changing it, specially if we are constrained by compatibility.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's solely constrained by compatibility at this point, unfortunately.

With 20/20 hindsight, we would have had the nomad/structs version store only the CSIVolumeClaims and not allocations (which has been a huge complication with respect to garbage collected jobs and allocations), and then had this API struct return WriteAllocs map[string]*AllocationListStub and ReadAllocs map[string]*AllocationListStub, without an Allocations field at all. See #8734 for more

@tgross tgross added this to the 1.0 milestone Nov 18, 2020
@tgross tgross requested a review from backspace November 23, 2020 15:07
@tgross tgross mentioned this pull request Nov 25, 2020
3 tasks
Copy link
Contributor

@DingoEatingFuzz DingoEatingFuzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a note on performance, but I'll let you decide if it's worth changing.

ui/app/serializers/volume.js Outdated Show resolved Hide resolved
hash.ReadAllocations = Object.keys(readAllocs).map(bindIDToAlloc(readAllocs));
hash.WriteAllocations = Object.keys(writeAllocs).map(bindIDToAlloc(writeAllocs));
hash.ReadAllocations = Object.keys(readAllocs).map(bindIDToAlloc(hash.Allocations));
hash.WriteAllocations = Object.keys(writeAllocs).map(bindIDToAlloc(hash.Allocations));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know off the top of my head if hash sticks around or if a copy is what gets inserted into the store. It wouldn't hurt to add a delete hash.Allocations just to err on the side of caution.

The API is missing values for `ReadAllocs` and `WriteAllocs` fields, resulting
in allocation claims not being populated in the web UI. These fields mirror
the fields in `nomad/structs.CSIVolume`. Returning a separate list of stubs
for read and write would be ideal, but this can't be done without either
bloating the API response with repeated full `Allocation` data, or causing a
panic in previous versions of the CLI.

The `nomad/structs` fields are persisted with nil values and are populated
during RPC, so we'll do the same in the HTTP API and populate the `ReadAllocs`
and `WriteAllocs` fields with a map of allocation IDs, but with null
values. The web UI will then create its `ReadAllocations` and
`WriteAllocations` fields by mapping from those IDs to the values in
`Allocations`, instead of flattening the map into a list.
@tgross tgross force-pushed the b-csi-api-readwriteallocs branch from 6b246ee to 198264e Compare November 25, 2020 20:47
@tgross tgross force-pushed the b-csi-api-readwriteallocs branch from 198264e to d095329 Compare November 25, 2020 20:52
@github-actions
Copy link

github-actions bot commented Dec 8, 2022

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nomad CSI volume status UI page never shows allocations depending on the volume
3 participants