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

Day, Phil philip.day at hp.com
Thu Jan 23 17:17:45 UTC 2014


> -----Original Message-----
> From: Sylvain Bauza [mailto:sylvain.bauza at bull.net]
> Sent: 22 January 2014 10:24
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds
> 
> Le 22/01/2014 02:50, Jay Pipes a écrit :
> >
> > Yup, agreed. It's difficult to guess what the capacity implications
> > would be without having solid numbers on customer demands for this
> > functionality, including hard data on how long such instances would
> > typically live (see my previous point about re-using compute hosts for
> > other purposes once the last dedicated instance is terminated on that
> > host).
> >
> > Best,
> > -jay
> >
> >
> 
> My personal opinion (but I can be wrong) is that such feature would only be
> accepted by operators only if there is some termination period defined when
> you create a dedicated instance.
> Again, what happens when the lease (or the lock-in) ends should be defined
> by the operator, on his own convenience, and that's why Climate is
> behaviour-driven by configuration flags for lease termination.
> 
I don't think that concept belongs in Nova, and I don't think in practice many people would accept a lease that they couldn't extend if they found their workload needed to run a bit longer.

> 
> Back to the initial subject, I think that's pretty good having such dedicated
> instances model in Nova (thanks to an API extension, which could be non-
> core), but the instance lifecycle (in case of termination
> period) should stay in Climate, IMHO.
> 
> -Sylvain

Just to be clear I'm not advocating putting any form of automated instance life-cycle into Nova - I agree that belongs in an external system like Climate.

However for a reservations model to work efficiently it seems to be you need two complementary types of resource available - for every least you accept promising resource at a certain point you need to have some resource that you can free up, otherwise you have to allocate the resource now to be sure it will be available at the required time in the future (which kind of negates the point of a reservation).    That is unless you're an airline operator, in which case you can of course sell an infinite number of seats on any plane ;-)

So it feels like as well as users being able to say "This instance must be started on this date"  you also need the other part of the set which is more like the spot instances which the user pays less for on the basis that they will be deleted if needed.     Both types should be managed by Climate not Nova.    Of course Climate would also I think need a way to manage when spot instances go away - it would be a problem to depend on X spot instance being there to  match the capacity of a lease only to find they had been deleted by the user in Nova some time ago, and the capacity now used for something else.


  



More information about the OpenStack-dev mailing list