[openstack-dev] [nova] Overview of local disk serial numbers series for reviewers

Matthew Booth mbooth at redhat.com
Thu Dec 21 15:43:44 UTC 2017

This series is ready for review. As normal I've done my best to break it up
into logically separate changes, so it's currently 15 patches long. I've
also done my best to write commit messages with the reviewer in mind. If
something looks weird, please check if I called it out in the commit

This email is an overview of the series to help see all 15 patches in
context. The spec is here:


The patch series is here:


* Add a uuid to BlockDeviceMapping

  https://review.openstack.org/242602 Add uuid column to BlockDeviceMapping
  https://review.openstack.org/242603 Make BlockDeviceMapping object
support uuid
  https://review.openstack.org/525599 Add an online migration for BDM.uuid

The first 2 were actually originally Dan Smith's patches from 2015,
resurrected for the second time. I've cribbed heavily from the original
patches and also the recent migration uuid patches. I've added a bunch of
robustification to the potentially racy bits, though, so they differ in
some details.

We want the libvirt driver to use this uuid as a serial number when
creating a guest. We now need to expose it to the libvirt driver for all

* Expose BlockDeviceMapping.uuid to drivers

  https://review.openstack.org/524167 DriverBlockDevice: make subclasses
inherit _proxy_as_attr
  https://review.openstack.org/529037 Expose BDM uuid to drivers

Drivers don't consume BlockDeviceMapping directly. Instead,
BlockDeviceMapping objects are translated to DriverBlockDevice objects and
passed in the block_device_info struct. These 2 changes simply add uuid to
existing DriverBlockDevice objects.

* Expose the local root disk BDM to drivers

  https://review.openstack.org/526346 Give volume DriverBlockDevice classes
a common prefix
  https://review.openstack.org/526347 Add DriverLocalImageBlockDevice
  https://review.openstack.org/529028 Rename block_device_info_get_root
  https://review.openstack.org/529029 Add local_root to block_device_info

Unfortunately, for reasons I'm still not entirely clear on
block_device_info has never contained a DriverBlockDevice object
representing a local root disk. The patches create a new DriverBlockDevice
class for a local root disk, and add it to block_device_info. We do this in
such a way that drivers which don't expect it to be there will never notice

At this point in the series, drivers have access to BDM.uuid for all of an
instance's disks.

* Fix an array of incorrect uses of DriverBlockDevice and block_device_info

  https://review.openstack.org/528362 Expose driver_block_device fields as
  https://review.openstack.org/528363 Pass DriverBlockDevice to
  https://review.openstack.org/527916 Use real block_device_info data in
libvirt tests
  https://review.openstack.org/529328 Fix libvirt volume tests passing
invalid disk_info

We're going to make changes which require BDM.uuid to be available.
Unfortunately we hardcode BDM data all over the place. That's all going to
break, even when the change isn't relevant to the test in question, which
it isn't 95% of the time. This mini-series focuses on using real data
everywhere we can. This reduces a ton of noise later.

The specific driver for the second patch in the series (to
driver.attach_volume) is that the libvirt driver needs a DriverBlockDevice
there, and was creating a fake one in non-test code.

At this point in the series all relevant test and non-test code is actually
using the new data. This means we can make changes in the libvirt driver
which require this new data without breaking everything.

* Implement local disk serial numbers for the libvirt driver

  https://review.openstack.org/529329 Pass disk_info dict to libvirt_info
  https://review.openstack.org/529380 Local disk serial numbers for the
libvirt driver

Here we finally make the libvirt driver-specific changes to expose BDM uuid
as a serial number for local disks.

Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171221/4d604c76/attachment.html>

More information about the OpenStack-dev mailing list