<div dir="ltr">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 clobber itself.<div><br></div><div>-Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 10:32 AM, Ivan Kolodyazhny <span dir="ltr"><<a href="mailto:e0ne@e0ne.info" target="_blank">e0ne@e0ne.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi developers and operators,</div><div>I would like to get any feedback from you about my idea before I'll start work on spec.<br></div><div><br></div>In Nova, we've got max_concurrent_builds option [1] to set 'Maximum number of instance builds to run concurrently' per each compute. There is no equivalent Cinder.<div><br></div><div>Why do we need it for Cinder? IMO, it could help us to address following issues:</div><div><ul><li>Creation of N volumes at the same time increases a lot of resource usage by cinder-volume service. Image caching feature [2] 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.</li><li>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.</li><li>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.</li><li>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.</li></ul><div><br></div><div>[1] <a href="https://github.com/openstack/nova/blob/283da2bbb74d0a131a66703516d16698a05817c7/nova/conf/compute.py#L161-L163" target="_blank">https://github.com/openstack/nova/blob/283da2bbb74d0a131a66703516d16698a05817c7/nova/conf/compute.py#L161-L163</a></div><div>[2] <a href="https://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html" target="_blank">https://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html</a></div><div><br clear="all"><div><div><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div>
</div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>