upcoming: [M3-8465] – Add "Volume Encryption" section to "Create and Attach Volume" drawer#10837
Conversation
…TORAGE_CLIENT_LIBRARY_UPDATE_REQUIRED_COPY; add Volume Encryption section to LinodeVolumeCreateForm
…isable Create Volume when user needs to reboot linode for client library update
…l display of client library copy; minor docs update
…or to use custom Autocomplete instead of MUI Autocomplete directly
There was a problem hiding this comment.
Just linter changes
| alerts: LinodeAlerts; | ||
| backups: LinodeBackups; | ||
| bs_encryption_supported?: boolean; // @TODO BSE: Remove optionality once BSE is fully rolled out | ||
| capabilities?: string[]; // @TODO BSE: Remove optionality once BSE is fully rolled out |
There was a problem hiding this comment.
May not be reflected in the API spec (yet), but this is how it was actually implemented. Reach out for Slack convo if needed.
| ui.autocompletePopper | ||
| .findByTitle(volume.label) | ||
| .should('be.visible') | ||
| .click(); |
There was a problem hiding this comment.
@jdamore-linode It seems that everything is good up until this point, and then the assertion on L228 causes the failure. Did some console.log'ing with the Cypress test running and clientLibraryCopyVisible in LinodeVolumeAddDrawer.tsx was never getting set to true for the "Attach Existing Volume" flow. I'm not sure why that is; it definitely works using the actual UI 🤔
There was a problem hiding this comment.
I see! When Cypress selects the Volume, Cloud fires off a GET request to /volumes/:id for the selected Volume. Since we're using a mock Volume, the response is 404ing so the attach form doesn't know that the Volume is encrypted.
Mocking that request fixes the issue, but surprisingly we don't have a mock util for that endpoint. You can add one to cypress/support/intercepts/volumes.ts:
/**
* Intercepts GET request to fetch a Volume and mocks response.
*
* @param volume - Volume with which to mock response.
*
* @returns Cypress chainable.
*/
export const mockGetVolume = (volume: Volume): Cypress.Chainable<null> => {
return cy.intercept('GET', apiMatcher(`volumes/${volume.id}`), makeResponse(volume));
};Then you can set it up right around where you mock the other Volumes request at line ~198:
mockGetVolumes([volume]).as('getVolumes');
mockGetVolume(volume);That caused the library update message to display for me and allowed the test to pass!
There was a problem hiding this comment.
Awesome, thanks for helping get to the bottom of that!
There was a problem hiding this comment.
Just linter changes aside from L187-190
There was a problem hiding this comment.
Just linter changes
…object to 'capabilities'
… client library update notices in Create/Attach Volume drawer
…Create/Attach Volume drawer
|
Coverage Report: ✅ |
bnussman-akamai
left a comment
There was a problem hiding this comment.
We can also add invalidations in packages/manager/src/queries/volumes/events.ts for the new query key
| // Invalidate the volume | ||
| queryClient.invalidateQueries({ | ||
| queryKey: volumeQueries.volume(volumeId).queryKey, | ||
| }); | ||
| }, |
There was a problem hiding this comment.
Because volume detaches take time to happen on the backend, I don't think we get any value from invalidating the Volume immediately. We can probably remove this.
The invalidation should happen when the volume detaches finishes in packages/manager/src/queries/volumes/events.ts
There was a problem hiding this comment.
@bnussman-akamai From my testing, I've only seen volume_detach events come through with a status of notification.
To clarify, do you think adding an invalidation for something like the event.action === 'volume_detach' && event.status === 'notification' case is sufficient in packages/manager/src/queries/volumes/events.ts, or are you proposing changes beyond that?
There was a problem hiding this comment.
Adding the following to line 18ish of events.ts should cover it
if (event.entity) {
invalidateQueries({
queryKey: volumeQueries.volume(event.entity.id).queryKey,
});
}|
I was able to test the user journey as described in the PR description and verified the UI updates. The following feedback is not related to the code changes in this PR. I feel that the user should be able to reboot the Linode from within the Create Volume drawer. With this current implementation, the user is able to configure the Volume they want to Create and Attach, but after checking the box for encryption, the Create Volume button is disabled and we essentially make the customer close the drawer, reboot the Linode, and configure the Volume all over again. |
There was a problem hiding this comment.
Nice work confirming the UX changes and functionality as mentioned in the PR description.
Question - To be consistent should we show the notice "This Linode requires client libraries... " in this flow as well ? Ignore the above one I see this is included in this PR

Description 📝
Add "Volume Encryption" section to "Create and Attach Volume" drawer
Changes 🔄
useVolumeQueryuseDetachVolumeMutationto accommodate invalidation ofuseVolumeQuery)VolumeSelectrefactor to use our customAutocompletecomponent rather than MUI's directlyLinodeVolumeAddDrawerLinodeVolumeCreateFormTarget release date 🗓️
9/16/24
Preview 📷
How to test 🧪
Prerequisites
Point at the dev environment with the
blockstorage-encryptiontag on your account. The linode you use should have acapabilitiesarray that does not containblockstorage_encryption. Without one or both of those, you should not observe any of the below.Verification steps
As an Author I have considered 🤔