-
Notifications
You must be signed in to change notification settings - Fork 930
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
Storage: Rework volume volatile.uuid
patch
#13162
Conversation
I just saw I could also make the |
This patch supersedes patchStorageSetVolumeUUID as it isn't affected by the leader election. Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
0051432
to
2dc5a41
Compare
2dc5a41
to
c309ce8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do all of this inside a single transaction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but this is looking a lot cleaner
Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
Signed-off-by: Julian Pelizäus <julian.pelizaeus@canonical.com>
c309ce8
to
3e4eb17
Compare
Absolutely, I haven't really thought about using one. Would you see any impact by not using a transaction? |
If one fails it'll fallback. But im not sure we want this in this case. Happy to leave as is. |
This reworks the patch added in #12840 so that it always applies the new
volatile.uuid
in any case without needing to rely on the LXD clusters leader election.I tried to reuse the same select query for all three cases, not sure if it's worth adding this complexity but it looks cleaner in my opinion.
Additionally I have fixed a bug in which new image volumes don't get a new
volatile.uuid
. This was missed whilst introducing the newGetNewVolume()
function which now also adds avolatile.uuid
to the volume's config.