openstack/nova-specs
Code Issues Proposed changes
acd44e35bc
nova-specs/specs/stein/approved/conf-max-attach-volumes.rst
melanie witt 1846d5caa7 Update blueprint name so spec matches launchpad 
I updated the name of the launchpad spec to match the spec filename
as tooling like 'move implemented specs' depends on the names
matching.

Change-Id: I122904371f6999e7accc0618a2d867c4cf06aab9
2018-10-02 19:09:21 +00:00

5.7 KiB
Raw Blame History

Configure maximum number of volumes to attach

https://blueprints.launchpad.net/nova/+spec/conf-max-attach-volumes

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

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.

Revisions
Release Name Description
Stein Introduced