[openstack-dev] [openstack-operators][cinder] max_concurrent_builds in Cinder
mr.alex.meade at gmail.com
Mon May 23 18:59:03 UTC 2016
This sounds like a good idea to me. The queue doesn't handle this since we
just read everything off immediately anyways. I have seen issues where
customers have to write scripts that build 5 volumes, sleep, then build
more until they get >100 volumes. Just because a Cinder volume service will
On Mon, May 23, 2016 at 10:32 AM, Ivan Kolodyazhny <e0ne at e0ne.info> wrote:
> Hi developers and operators,
> I would like to get any feedback from you about my idea before I'll start
> work on spec.
> In Nova, we've got max_concurrent_builds option  to set 'Maximum number
> of instance builds to run concurrently' per each compute. There is no
> equivalent Cinder.
> Why do we need it for Cinder? IMO, it could help us to address following
> - Creation of N volumes at the same time increases a lot of resource
> usage by cinder-volume service. Image caching feature  could help us a
> bit in case when we create volume form image. But we still have to upload N
> images to the volumes backend at the same time.
> - Deletion on N volumes at parallel. Usually, it's not very hard task
> for Cinder, but if you have to delete 100+ volumes at once, you can fit
> different issues with DB connections, CPU and memory usages. In case of
> LVM, it also could use 'dd' command to cleanup volumes.
> - It will be some kind of load balancing in HA mode: if cinder-volume
> process is busy with current operations, it will not catch message from
> RabbitMQ and other cinder-volume service will do it.
> - From users perspective, it seems that better way is to create/delete
> N volumes a bit slower than fail after X volumes were created/deleted.
> Ivan Kolodyazhny,
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev