Open Stack

+operators (I forgot)

On 6/7/2018 1:07 PM, Matt Riedemann wrote:
> On 6/7/2018 12:56 PM, melanie witt wrote:
>> Recently, we've received interest about increasing the maximum number 
>> of allowed volumes to attach to a single instance > 26. The limit of 
>> 26 is because of a historical limitation in libvirt (if I remember 
>> correctly) and is no longer limited at the libvirt level in the 
>> present day. So, we're looking at providing a way to attach more than 
>> 26 volumes to a single instance and we want your feedback.
> 
> The 26 volumes thing is a libvirt driver restriction.
> 
> There was a bug at one point because powervm (or powervc) was capping 
> out at 80 volumes per instance because of restrictions in the 
> build_requests table in the API DB:
> 
> https://bugs.launchpad.net/nova/+bug/1621138
> 
> They wanted to get to 128, because that's how power rolls.
> 
>>
>> We'd like to hear from operators and users about their use cases for 
>> wanting to be able to attach a large number of volumes to a single 
>> instance. If you could share your use cases, it would help us greatly 
>> in moving forward with an approach for increasing the maximum.
>>
>> Some ideas that have been discussed so far include:
>>
>> A) Selecting a new, higher maximum that still yields reasonable 
>> performance on a single compute host (64 or 128, for example). Pros: 
>> helps prevent the potential for poor performance on a compute host 
>> from attaching too many volumes. Cons: doesn't let anyone opt-in to a 
>> higher maximum if their environment can handle it.
>>
>> B) Creating a config option to let operators choose how many volumes 
>> allowed to attach to a single instance. Pros: lets operators opt-in to 
>> a maximum that works in their environment. Cons: it's not discoverable 
>> for those calling the API.
> 
> I'm not a fan of a non-discoverable config option which will impact API 
> behavior indirectly, i.e. on cloud A I can boot from volume with 64 
> volumes but not on cloud B.
> 
>>
>> C) Create a configurable API limit for maximum number of volumes to 
>> attach to a single instance that is either a quota or similar to a 
>> quota. Pros: lets operators opt-in to a maximum that works in their 
>> environment. Cons: it's yet another quota?
> 
> This seems the most reasonable to me if we're going to do this, but I'm 
> probably in the minority. Yes more quota limits sucks, but it's (1) 
> discoverable by API users and therefore (2) interoperable.
> 
> If we did the quota thing, I'd probably default to unlimited and let the 
> cinder volume quota cap it for the project as it does today. Then admins 
> can tune it as needed.
> 


-- 

Thanks,

Matt