From b532c276698e9455168b03bd5ee067265ff5db7a Mon Sep 17 00:00:00 2001 From: melanie witt Date: Tue, 28 Aug 2018 22:52:51 +0000 Subject: [PATCH] Propose configurable maximum number of volumes to attach Related to blueprint nova-improvement-of-maximum-attach-volumes-more-than-26-vols Change-Id: I78d13c14998a4f7552aa70408e14185263f07a18 --- .../approved/conf-max-attach-volumes.rst | 194 ++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 specs/stein/approved/conf-max-attach-volumes.rst diff --git a/specs/stein/approved/conf-max-attach-volumes.rst b/specs/stein/approved/conf-max-attach-volumes.rst new file mode 100644 index 000000000..cb6d86e87 --- /dev/null +++ b/specs/stein/approved/conf-max-attach-volumes.rst @@ -0,0 +1,194 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +============================================= +Configure maximum number of volumes to attach +============================================= + +https://blueprints.launchpad.net/nova/+spec/nova-improvement-of-maximum-attach-volumes-more-than-26-vols + +Currently, there is a limitation in the libvirt driver restricting the maximum +number of volumes to attach to a single instance to 26. Depending on virt +driver and operator environment, operators would like to be able to attach +more than 26 volumes to a single instance. We propose adding a configuration +option that operators can use to select the maximum number of volumes allowed +to attach to a single instance. + + +Problem description +=================== + +We've had customers ask for the ability to attach more than 26 volumes to a +single instance and we've seen launchpad bugs opened from users trying to +attach more than 26 volumes (see `References`_). Because the supportability of +any number of volumes depends heavily on which virt driver is being used and +the operator's particular environment, we propose to make the maximum +configurable by operators. Choosing an appropriate maximum number will require +tuning with the specific virt driver and deployed environment, so we expect +operators to set the maximum, test, tune, and adjust the configuration option +until the maximum is working well in their environment. + +Use Cases +--------- + +* Operators wish to be able to attach a maximum number of volumes to a single + instance, with the ability to choose a maximum well-tuned for their + environments. + +Proposed change +=============== + +When a user attempts to attach more than 26 volumes with the libvirt driver, +the attach fails in the ``reserve_block_device_name`` method in nova-compute, +which is eventually called by the ``attach_volume`` method in nova-api. The +``reserve_block_device_name`` method calls +``self.driver.get_device_name_for_instance`` to get the next available device +name for attaching the volume. If the driver has implemented the method, this +is where an attempt to go beyond the maximum allowed number of volumes to +attach, will fail. The libvirt driver fails after 26 volumes have been +attached. Drivers that have not implemented ``get_device_name_for_instance`` +appear to have no limit on the maximum number of volumes. The default +implementation of ``get_device_name_for_instance`` is located in the +``nova.compute.utils`` module. Only the libvirt driver has provided its own +implementation of ``get_device_name_for_instance``. + +The ``reserve_block_device_name`` method is a synchronous RPC call (not cast). +This means we can have the configured allowed maximum set differently per +nova-compute and still fail fast in the API if the maximum has been exceeded. + +We propose to add a new configuration option ``[compute]max_volumes_to_attach`` +IntOpt to use to configure the maximum allowed volumes to attach to a single +instance per nova-compute. This way, operators can set it appropriately +depending on what virt driver they are running and what their deployed +environment is like. The default will be unlimited (-1) to keep the current +behavior for all drivers except the libvirt driver. + +The configuration option will be enforced in the +``get_device_name_for_instance`` methods, using the count of the number of +already attached volumes. Upon failure, an exception will be propagated to +nova-api via the synchronous RPC call to nova-compute, and the user will +receive a 403 error (as opposed to the current 500 error). + +Alternatives +------------ + +Other ways we could solve this include: choosing a new hard-coded maximum only +for the libvirt driver or creating a new quota limit for "maximum volumes +allowed to attach" (see the ML thread in `References`_). + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +Deployers will be able to set the ``[compute]max_volumes_to_attach`` +configuration option to control how many volumes are allowed to be attached +to a single instance per nova-compute in their deployment. + +Developer impact +---------------- + +None + +Upgrade impact +-------------- + +None + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + melwitt + +Other contributors: + yukari-papa + +Work Items +---------- + +* Add a new configuration option ``[compute]max_volumes_to_attach``, IntOpt +* Modify (or remove) the libvirt driver's implementation of the + ``get_device_name_for_instance`` method to accomodate more than 26 volumes +* Add enforcement of ``[compute]max_volumes_to_attach`` to the + ``get_device_name_for_instance`` methods +* Add handling of the raised exception in the API to translate to a 403 to the + user, if the maximum number of allowed volumes is exceeded + + +Dependencies +============ + +None + +Testing +======= + +The new functionality will be tested by new unit and functional tests. + + +Documentation Impact +==================== + +The documentation for the new configuration option will be automatically +included in generated documentation of the configuration reference. + +References +========== + +* https://bugs.launchpad.net/nova/+bug/1770527 + +* https://bugs.launchpad.net/nova/+bug/1773941 + +* http://lists.openstack.org/pipermail/openstack-dev/2018-June/131289.html + + +History +======= + +Optional section intended to be used each time the spec is updated to describe +new design, API or any database schema updated. Useful to let reader understand +what's happened along the time. + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Stein + - Introduced