Support Sheepdog ephemeral disks for libvirt driver¶
Add support for Sheepdog instance ephemeral disks.
Sheepdog block devices can already be attached to QEMU and KVM virtual machines. Nova’s libvirt driver supports most of the functionality. The only additional changes are to the image-backend drivers. Both Glance and Cinder support sheepdog backends, so this would complement the efforts made in those projects.
This change would extend several parts of the libvirt driver. In general, these changes are very similar to the changes required for the RBD driver. These changes would bring Sheepdog support into feature-parity with RBD, QEMU and other libvirt image drivers.
nova.virt.libvirt.driver would be extended with cleanup functions for Sheepdog, in the same way that
cleanup_rbd_instancedoes for the RBD backend.
Imagesubclass class would be added to
Helper functions would be added to
/etc/nova/rootwrap.d/filters would be extended to support rootwrap on the
dogcommand used to interact with Sheepdog.
See Deployer impact for configuration changes.
Cinder has existing support for Sheepdog volumes. One alternative is to use that driver and only launch instances from volumes. There are two problems with this option. First, it would not support instance disks that are deleted after the instance is destroyed. Second, for the end-user it requires additional steps to provision the volume before the instance is booted.
Data model impact¶
REST API impact¶
None. This blueprint makes no REST API changes.
Rootwrap of ‘dog’ command on nova-compute machines.
None. No plans for new notifications.
Other end user impact¶
None. This blueprint has no impact on python-novaclient or any other end-user interface.
Other deployer impact¶
To use this feature, a deployer must first set up a sheepdog cluster and then make several configuration changes to nova on machines running the nova-compute process. If Sheepdog is to be used with Glance and Cinder, the deployer must also make the appropriate configuration changes for those services.
To setup a Sheepdog cluster, follow the install guide provided by
Sheepdog 1. After setting up a Sheepdog cluster, each nova-compute
process must be configured. The following options must be set under
[libvirt] section of
images_type=sheepdogThis must be set to indicate that sheepdog should be used.
images_sheepdog_host=locahostChange this if the machine running the nova-compute process is not a member of the sheepdog cluster, or is not acting as a gateway node within the cluster.
images_sheepdog_port=7000`Change this if the sheep process is listening on a different port than the default.
For sites doing continuous deployment, this change will have no impact until
the deployer changes the
images_type setting to deliberately switch a
nova-compute machine to use Sheepdog.
There are no database migrations required for this change.
This change would add an additional disk-backend to the libvirt driver, slightly increasing code support costs.
- Primary assignee:
<scott-devoid> Scott Devoid
- Other contributors:
Implement basic support for Sheepdog images booted from a Glance image.
Implement snapshot support.
Devstack integration is required before tempest can run functional tests against the Sheepdog drivers for Nova, Glance and Cinder. A patch has been proposed which would use Sheepdog for each service. 2
This, I think, would result in many functional tests of the Sheepdog drivers via the Tempest tests. However, a Jenkins job would need to be defined and VMs would need to be provisioned to run the jobs. It is not clear if openstack-infra is willing or capable of committing to a proliferation of CI test runs. There is a Juno Summit scheduled for this. 3
Configuration reference would need to be updated with the new configuration options. See the Deployer Impact section.
Cloud Administer or Operations guide should be updated with a section which describes in detail how to configure Sheepdog for nova and what sort of considerations should be taken into account, e.g. cluster size, Zookeeper vs Corosync, the use of gateway nodes.
These documentation changes would happen as part of this blueprint.