[openstack-dev] Next steps for Whole Host allocation / Pclouds

Jay Pipes jaypipes at gmail.com
Mon Jan 20 17:50:43 UTC 2014

On Mon, 2014-01-20 at 17:49 +0100, Sylvain Bauza wrote:
> Hi Jay,
> Le 20/01/2014 17:34, Jay Pipes a écrit :
> > On Mon, Jan 20, 2014 at 11:18 AM, Sylvain Bauza
> > <sylvain.bauza at bull.net> wrote:
> >         Jay, please be aware of the existence of Climate, which is a
> >         Stackforge project for managing dedicated resources (like
> >         AWS reserved instances). This is not another API extension,
> >         but another API endpoint for creating what we call "leases"
> >         which can be started now or in the future and last for a
> >         certain amount of time. We personnally think there is a
> >         space for Reservations in Openstack, and this needs to be
> >         done as a service.
> > 
> > 
> > Hi Sylvain! Hope all is well with you :)
> Thanks, doing well but a bit under pressure, as Climate has its 0.1
> milestone this week...

Understood :)

> > 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/aggregate_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

But I believe that the two concerns can be tackled separately.


More information about the OpenStack-dev mailing list