<tt><font size=2>Dan Smith <dms@danplanet.com> wrote on 06/08/2018

08:46:01 AM:<br><br>> From: Dan Smith <dms@danplanet.com></font></tt><br><tt><font size=2>> To: melanie witt <melwittt@gmail.com></font></tt><br><tt><font size=2>> Cc: "OpenStack Development Mailing List

\(not for usage questions\)"<br>> <openstack-dev@lists.openstack.org>, openstack-operators@lists.openstack.org</font></tt><br><tt><font size=2>> Date: 06/08/2018 08:48 AM</font></tt><br><tt><font size=2>> Subject: Re: [openstack-dev] [nova] increasing

the number of allowed > volumes attached per instance > 26</tt> <tt><font size=2>>  > > Some ideas that have been discussed so far include: >  > FYI, these are already in my order of preference. >  > > A) Selecting a new, higher maximum that still yields reasonable > > 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>> </font></tt><br><br><tt><font size=2>As long as this can be done on a per virt driver basis

as Dan says</font></tt><br><tt><font size=2>I think also would prefer this option.</font></tt><br><br><tt><font size=2>Actually the meaning fully number is much higher that

500 for powervm.</tt> <tt><font size=2>I'm thinking the powervm limit could likely be 4096ish.

On powervm we have </font></tt><br><tt><font size=2>a OS where the meaningful limit is 4096 volumes but

routinely most</font></tt><br><tt><font size=2>operators would have between 1000-2000.</font></tt><br><br><tt><font size=2>-Gerald</font></tt><br><tt><font size=2><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: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> </font></tt><a href=https://urldefense.proofpoint.com/v2/url?><tt><font size=2>https://urldefense.proofpoint.com/v2/url?</font></tt></a><tt><font size=2><br>> u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-<br>> siA1ZOg&r=i0r4x6W1L_PMd5Bym8J36w&m=Vg5MEvB0VELjModDoJF8PGcmUinnq-<br>> kfFxavTqfnYYw&s=xe_2YmabBZEJJmtBK-4LZPh68rG3UI6dVqoZq6zKlIA&e=<br>> <br></font></tt><BR>