<div dir="ltr">Hi,<div>this looks reasonable to me but I would prefer B.</div><div>In this case the operator can configure the hard limit.</div><div>I don't think we more granularity or expose it using the API.</div><div><br></div><div>Belmiro</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 8, 2018 at 3:46 PM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Some ideas that have been discussed so far include:<br>
<br>
FYI, these are already in my order of preference.<br>
<br>
> A) Selecting a new, higher maximum that still yields reasonable<br>
> performance on a single compute host (64 or 128, for example). Pros:<br>
> helps prevent the potential for poor performance on a compute host<br>
> from attaching too many volumes. Cons: doesn't let anyone opt-in to a<br>
> higher maximum if their environment can handle it.<br>
<br>
I prefer this because I think it can be done per virt driver, for<br>
whatever actually makes sense there. If powervm can handle 500 volumes<br>
in a meaningful way on one instance, then that's cool. I think libvirt's<br>
limit should likely be 64ish.<br>
<br>
> B) Creating a config option to let operators choose how many volumes<br>
> allowed to attach to a single instance. Pros: lets operators opt-in to<br>
> a maximum that works in their environment. Cons: it's not discoverable<br>
> for those calling the API.<br>
<br>
This is a fine compromise, IMHO, as it lets operators tune it per<br>
compute node based on the virt driver and the hardware. If one compute<br>
is using nothing but iSCSI over a single 10g link, then they may need to<br>
clamp that down to something more sane.<br>
<br>
Like the per virt driver restriction above, it's not discoverable via<br>
the API, but if it varies based on compute node and other factors in a<br>
single deployment, then making it discoverable isn't going to be very<br>
easy anyway.<br>
<br>
> C) Create a configurable API limit for maximum number of volumes to<br>
> attach to a single instance that is either a quota or similar to a<br>
> quota. Pros: lets operators opt-in to a maximum that works in their<br>
> environment. Cons: it's yet another quota?<br>
<br>
Do we have any other quota limits that are per-instance like this would<br>
be? If not, then this would likely be weird, but if so, then this would<br>
also be an option, IMHO. However, it's too much work for what is really<br>
not a hugely important problem, IMHO, and both of the above are<br>
lighter-weight ways to solve this and move on.<br>
<br>
--Dan<br>
<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>
</blockquote></div>