Skip to content

Instantly share code, notes, and snippets.

@akhilerm

akhilerm/BlockDevice upgrade

Last active August 4, 2020 04:15
Show Gist options
  • Save akhilerm/cb9cfff929bff00efaa0d3f70d25a116 to your computer and use it in GitHub Desktop.
Save akhilerm/cb9cfff929bff00efaa0d3f70d25a116 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
BlockDevice upgrade
Flowchart for local pv upgrade
NOTE: Does not support upgrade of localPV rawblock
For Cstor, the same flowchart as below applies, but instead of using FSUUID annotation, partition table UUID
annotation will be used.
Display the source blob
Display the rendered blob
Raw
LocalPVFSUpgrade.pdf
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@kmova
Copy link

kmova commented Jul 30, 2020 •
edited
Loading

BlockDevice (gptuuid)

  • Here the resource can be both claimed or unclaimed.
  • This flow chart seems to be triggered after identifying the block device is used for Local PV. But it may be possible that due to a restart/race condition, the BD can get into the unclaimed or released state due to a Local PV getting deleted.
  • In case there BD is in the unclaimed state - continue to migrate.
  • In case of claimed/released - continue to update the properties (Confirm with Akhil ?)
  • [ This opens up a possibility of a corner case where during a release job, the underlying disk path can change. Need to raise another issue to add some kind of additional checks to ensure the wipefs is being executed on the intended disk. The cleanup job retry logic needs to be checked to see if a reboot of a node causes the disks to change the path and if the cleanup job wipes the correct disk. ]

BlockDevice (legacy virtual) + unclaimed ( unchanged properties)

  • BlockDevice (legacy virtual) + unclaimed
  • BlockDevice (legacy virtual) + unclaimed + w/ fs
    • In both these cases, a new BD will be created with FSUUID or GPT
    • A matching resource with old legacy uuid will be marked as legacy and indicate that it has been migrated. ( Confirm with Akhil?)

BlockDevice (legacy virtual) + unclaimed (changed properties)

  • BlockDevice (legacy virtual + path/host changed) + unclaimed
  • BlockDevice (legacy virtual + path/host changed) + unclaimed + w/ fs
    • Older Block Device will be marked as unkown
    • Older Block Device will be marked as legacy annotation. This resource could be deleted.

BlockDevice (legacy unique) + unclaimed (changed properties)

  • BlockDevice (legacy with serial/wwn) + unclaimed
  • BlockDevice (legacy with serial/wwn) + unclaimed + w/ fs
    • Older Block Device will be marked with legacy annotation
    • A new BD will be created with FSUUID or GPT
    • Older Block Device will be updated with the corresponding new BD
    • Older Block Device will be deleted ( Confirm with Akhil?). May be we need to keep the older block device intact in a state where it can't be claimed or is it safe to delete? When deleting these BD, no wipefs kind of operations should be performed.

BlockDevice (legacy virtual) + claimed (unchanged properties)

  • BlockDevice (legacy virtual) + claimed + w/ fs

    • Older Block Device will be marked with legacy annotation
    • Older Block Device will be updated with fs uuid information

  • BlockDevice (legacy virtual) + claimed + raw

    • Older Block Device will be marked with legacy annotation
    • Older Block Device will be updated with data fs uuid information. ( Confirm with Akhil?)

BlockDevice (legacy virtual) + claimed (changed properties)

  • BlockDevice (legacy virtual + path/host changed) + claimed + w/ fs
  • BlockDevice (legacy virtual + path/host changed) + claimed + raw
    • Older Block Device will be marked with legacy annotation
    • Older Block Device will be marked with status unknown
    • A new BD would have been created for this on the new node with FSUUID ( or with the information that could be obtained from raw).
    • Admin intervention is required to clean up and also update the details or link the older "unkown" BD with new BD. The new BD should be marked as used.

BlockDevice (legacy unique) + claimed

  • BlockDevice (legacy with serial/wwn) + claimed + w/ fs
  • BlockDevice (legacy with serial/wwn) + claimed + raw
    • Older Block Device will be marked with legacy annotation
    • Older Block Device will be updated with fs uuid information

BlockDevice (legacy virtual or unique) + released and unchanged properties

  • BlockDevice (legacy virtual) + released + fs
  • BlockDevice (legacy virtual) + released + raw
  • BlockDevice (legacy with serial/wwn) + released + fs
  • BlockDevice (legacy with serial/wwn) + released + raw
    • Older Block Device will be marked with legacy annotation

BlockDevice (legacy virtual or unique) + released and changed properties

  • BlockDevice (legacy virtual + path/host changed) + released + fs
  • BlockDevice (legacy virtual + path/host changed) + released + raw
    • Older Block Device will be marked with legacy annotation
    • Older Block Device will be marked with status unknown.
    • Manual operation may be needed to clean up.
    • Also, clean-up job should not be triggered on a released device. ( Confirm with Akhil)

@akhilerm
Copy link
Author

@kmova, There will be slight change in design for checking with FSUUID, found a bug when testing with multiple virtual devices:

  1. 2 virtual devices are connected to the node, One is claimed and one unclaimed.
  2. NDM is upgraded to latest version
  3. Node is rebooted and devices swap their path
  4. The above design updates the incorrect blockdevice , because it first finds a device with matching legacy UUID.

Solution:
Even after getting matching legacy UUID , a check for partitionuuid or fsuuid need to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment