On 07/24/2013 05:39 AM, Day, Phil wrote: > Hi Alex, > > I'm inclined to agree with others that I'm not sure you need the complexity > that this BP brings to the system. If you want to provide a user with a > choice about how much overcommit they will be exposed to then doing that in > flavours and the aggregate_instance_extra_spec filter seems the more natural > way to do this, since presumably you'd want to charge differently for those > and the flavour list is normally what is linked to the pricing model. > > I also like the approach taken by the recent changes to the ram filter where > the scheduling characteristics are defined as properties of the aggregate > rather than separate stanzas in the configuration file. > > An alternative, and the use case I'm most interested in at the moment, is > where we want the user to be able to define the scheduling policies on a > specific set of hosts allocated to them (in this case they pay for the host, > so if they want to oversubscribe on memory/cpu/disk then they should be able > to). The basic framework for this is described in this BP > https://blueprints.launchpad.net/nova/+spec/whole-host-allocation and the > corresponding wiki page (https://wiki.openstack.org/wiki/WholeHostAllocation. > I've also recently posted code for the basic framework built as a wrapper > around aggregates (https://review.openstack.org/#/c/38156/, > https://review.openstack.org/#/c/38158/ ) which you might want to take a look > at. > > Its not clear to me if what your proposing addresses an additional gap > between this and the combination of the aggregate_extra_spec filter + revised > filters to get their configurations from aggregates) ?
I really like your point about not needing to set things up via a config file. That's fairly limiting since you can't change it on the fly via the API. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
