On Tue, 2014-01-21 at 11:57 +0000, Day, Phil wrote: > > > > So, I actually don't think the two concepts (reservations and > > > > "isolated instances") are competing ideas. Isolated instances are > > > > actually not reserved. They are simply instances that have a > > > > condition placed on their assignment to a particular compute node > > > > that the node must only be hosting other instances of one or more > > > > specified projects (tenants). > > > > > > I got your idea. This filter [1] already does most of the work, > > > although it relies on aggregates and requires admin management. The > > > main issue with isolated instances is that it requires kind of > > > capacity planning for making sure you can cope with the load, that's > > > why we placed the idea of having such a placement scheduler. > > > > > > [1] : > > > > > https://github.com/openstack/nova/blob/master/nova/scheduler/filters/a > > > ggregate_multitenancy_isolation.py > > > > Right, the difference between that and my proposed solution would be > > there would be no dependency on any aggregate at all. > > > > I do understand your point about capacity planning in light of such > > scheduling > > functionality -- due to the higher likelihood that compute nodes would be > > unable to service a more general workload from other tenants. > > > > But I believe that the two concerns can be tackled separately. > > > Exactly - that's why I wanted to start this debate about the way forward for > the Pcloud Blueprint, which was heading into some kind of middle ground. As > per my original post, and it sounds like the three of us are at least aligned > I'm proposing to spilt this into two streams: > > i) A new BP that introduces the equivalent of AWS dedicated instances. > User - Only has to specify that at boot time that the instance must be > on a host used exclusively by that tenant. > Scheduler - ether finds a hoist which matches this constraint or it > doesn't. No linkage to aggregates (other than that from other filters), no > need for the aggregate to have been pre-configured > Compute Manager - has to check the constraint (as with any other > scheduler limit) and add the info that this is a dedicated instance to > notification messages > Operator - has to manage capacity as they do for any other such > constraint (it is a significant capacity mgmt issue, but no worse in my mind > that having flavors that can consume most of a host) , and work out how they > want to charge for such a model (flat rate additional charge for first such > instance, charge each time a new host is used, etc). > > I think there is clear water between this and the existing aggregate based > isolation. I also think this is a different use case from reservations. > It's *mostly* like a new scheduler hint, but because it has billing impacts I > think it needs to be more than just that - for example the ability to request > a dedicated instance is something that should be controlled by a specific > role. > > ii) Leave the concept of "private clouds within a cloud" to something that > can be handled at the region level. I think there are valid use cases here, > but it doesn’t make sense to try and get this kind of granularity within Nova.
Above sounds good to me. :) -jay _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
