On 2 February 2016 at 14:11, Sascha Vogt <sascha.v...@gmail.com> wrote: > Hi, > > Am 31.01.2016 um 18:57 schrieb John Garbutt: >> We need to make sure we don't have configuration values that change >> the semantic of our API. >> Such things, at a minimum, need to be discoverable, but are best avoided. > I totally agree on that. I > >>> I think an off-loaded / shelved resource should still count against the >>> quota being used (instance, allocated floating IPs, disk space etc) just >>> not the resources which are no longer consumed (CPU and RAM) >> >> OK, but that does mean unshelve can fail due to qutoa. Maybe thats OK? > For me that would be ok, just like a boot could fail. Even now I think > an unshelve can fail, because a new scheduling run is triggered and > depending on various things you could get a "no valid host" (e.g. we > have properties on Windows instances to only run them on a host with a > datacenter license. If that host is full (we only have one at the > moment), unshelve shouldn't work, should it?). > >> The quota really should live with the project that owns the resource. >> i.e. nova has the "ephemeral" disk quota, but glance should have the >> glance quota. > Oh sure, I didn't mean to have that quota in Nova just to have them in > general "somewhere". When I first started playing around with OpenStack, > I was surprised that there are no quotas for images and ephemeral disks. > > What is the general feeling about this? Should I ask on "operators" if > there is someone else who would like to have this added?
I think the best next step is to write up a nova-spec for newton: http://docs.openstack.org/developer/nova/process.html#how-do-i-get-my-code-merged But from a wider project view the quota system is very fragile, and is proving hard to evolve. There are some suggested approaches to fix that, but no one has had the time to take on that work. There is a bit of a backlog of quota features right now. Thanks, johnthetubaguy __________________________________________________________________________ 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
