Open Stack

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