> > > 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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
