[21.05] restore-single-files: reduce chance of UUID collision

[ctheune]

@flyingcircusio/release-managers

Release process

Impact:

none

Changelog:

• Our restore-single-file utility now handles situations better where multiple disks happen to have the same filesystem UUID, which can happen in image or cloning cases. (PL-132849)

• To avoid the issue of duplicate filesystem UUIDs (as is happening when VMs are or have been bootstrapped from the same base image) we now regenerate the XFS UUID upon every cold boot. (PL-132849)

• Full KVM host migrations use shorter lock retry intervals to reduce long tail finishing times. The maximum delay has been reduced from 80 seconds to 20 seconds. The average delay is expected to be around 10 seconds.

PR release workflow (internal)

• PR has internal ticket
• internal issue ID (PL-…) part of branch name
• internal issue ID mentioned in PR description text
• ticket is on Platform agile board
• ticket state set to Pull request ready
• if ticket is more urgent than within the next few days, directly contact a member of the Platform team

Design notes

• Provide a feature toggle if the change might need to be adjusted/reverted quickly depending on context. Consider whether the default should be on or off. Example: rate limiting.
• All customer-facing features and (NixOS) options need to be discoverable from documentation. Add or update relevant documentation such that hosted and guided customers can understand it as well.

Security implications

• Security requirements defined? (WHERE)

This affects restore reliability and improves our capacity of restoring backups without encountering roadblocks.

• Security requirements tested? (EVIDENCE)

restore script: manually tested
fc.qemu integration: covered with automated tests and manually tested