<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 23, 2016 at 8: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><div class="gmail_default" style="font-family:monospace,monospace">Just curious about a couple things: Is this attempting to solve a problem in the actual Cinder Volume Service or is this trying to solve problems with backends that can't keep up and deliver resources under heavy load? I get the copy-image to volume, that's a special case that certainly does impact Cinder services and the Cinder node itself, but there's already throttling going on there, at least in terms of IO allowed.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Also, I'm curious... would the exiting API Rate Limit configuration achieve the same sort of thing you want to do here? Granted it's not selective but maybe it's worth mentioning.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">If we did do something like this I would like to see it implemented as a driver config; but that wouldn't help if the problem lies in the Rabbit or RPC space. That brings me back to wondering about exactly where we want to solve problems and exactly which. If delete is causing problems like you describe I'd suspect we have an issue in our DB code (too many calls to start with) and that we've got some overhead elsewhere that should be eradicated. Delete is a super simple operation on the Cinder side of things (and most back ends) so I'm a bit freaked out thinking that it's taxing resources heavily.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><br></div></div>