> I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. > > I would really like NOT to see logic like this in any nova code: > >> if kvm|qemu: >> return 256 >> elif POWER: >> return 4000 >> elif: >> ...
It's insanity to try to find a limit that will work for everyone. PowerVM supports a billion, libvirt/kvm has some practical and theoretical limits, both of which are higher than what is actually sane. It depends on your virt driver, and how you're attaching your volumes, maybe how tightly you pack your instances, probably how many threads you give to an instance, how big your compute nodes are, and definitely what your workload is. That's a really big matrix, and even if we decide on something, IBM will come out of the woodwork with some other hypervisor that has been around since the Nixon era that uses BCD-encoded volume numbers and thus can only support 10. It's going to depend, and a user isn't going to be able to reasonably probe it using any of our existing APIs. If it's going to depend on all the above factors, I see no reason not to put a conf value in so that operators can pick a reasonably sane limit. Otherwise, the limit we pick will be wrong for everyone. Plus... if we do a conf option we can put this to rest and stop talking about it, which I for one am *really* looking forward to :) --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
