Open Stack

Hi Andrew,

Le 12/11/2013 21:50, Andrew Laski a écrit :
> On 11/06/13 at 09:47am, Sylvain Bauza wrote:
>> Hi,
>>
>> During the Design session 
>> https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we 
>> discussed the fact that this is not the role of Nova for doing atomic 
>> reservations in order to ensure the user needs will be met.
>
> We discussed that it's not Nova's role to do atomic reservations of 
> groups of resources.  But two phase commit came up a number of times 
> for single instance scheduling/reservations which would allow 
> reservations of groups to occur with some outside coordination.
>

Indeed you're right, the consensus was about nested InstanceGroups, 
where it was said it should be done outside Nova.
>>
>> I raised the point (and sorry for my bad accent, was stressy) that 
>> we're already trying to provide a reservation system for Openstack, 
>> called Climate (a Stackforge project).
>> I would really like to discuss with you all, Nova community, about 
>> the reservation system and ensure that we, at Climate, are on the 
>> good path.
>
> I think Climate has some interesting potential around capacity 
> planning and would like to see it integrate well with Nova.  But my 
> understanding of both proposals makes me think that the reservation 
> system that Climate wants to provide isn't the best solution for the 
> Instance Group work.  Instance Groups, or the longer term idea of 
> Resource Groups should be workable with two phase commit since it's 
> concerned about what can be placed at that moment.  Climate also 
> considers future placements which is very cool but leads(potentially) 
> to different design considerations and trade-offs.

Well, probably I jumped to the conclusion without waiting to see what 
InstanceGroups will actually be.
Let's follow the discussion on the InstanceGroups, and just keep in mind 
that Climate could help.
My main concern is just making sure we won't duplicate work on 
reservations themselves, that's it.

Climate is a quite new Stackforge project with little visibility, that's 
why I spoke about it.


>
> One thing that isn't clear to me from the etherpad 
> (https://etherpad.openstack.org/p/NovaIcehouse-ClimateInteractions) 
> and the discussion is what API behaviour in Nova would be ideal for 
> Climate?  You've listed questions about pclouds and host aggregates 
> and other things that Nova provides, but those seem like 
> implementation details to me.  What kinds of actions could Nova 
> provide that would allow Climate to function well?
>

Well, the issue we had is that we spent the 10 mins speaking about how 
Climate could ensure that the leases will be honored, and consequently I 
ran out of time speaking about the interactions by themselves.

Let me just clarify how we can do the math : Climate will provide an 
Host reservation Admin API allowing administrators to "dedicate" 
nova-computes to Climate (ie. putting them in an host aggregate called 
"freepool" with no ways for getting them elected by the Nova scheduler 
on a regular nova boot command).

We'll then keep a backlog of reservations mapped to hosts and 
consequently we will be sure that on an atomic fashion, any hosts 
selected won't already have VMs running on them.


That said, let's go back to your question and what Nova features would 
be nice for Climate :

  1/ as said, there is no clear consensus on about Pclouds or AZs. I was 
at the Pcloud design session, and I saw that Phil is not planning having 
them delivered in Icehouse. As a consequence, we will begin our 
implementation by using AZs, that should match our needs. Anyway, we'll 
provide an interface for managing what we call "Reservation Pools", and 
we will keep compatibility in between Pclouds and AZs in it. One side 
note is that we aren't using "Host Flavors" yet but rather an explicit 
dictionary of capabilities, that should be modified for exposing flavors 
instead, but not in the first Climate release.

  2/ So as to get host capabilities and as the resource tracker is not 
extensible, we made a design choice to implement an Hosts DB model 
having same attributes as in Nova (duplicate work, ergh.) with an 
associated table called "HostExtraCapabilities" with key/value pairs 
(see [1]). That's not perfect. The best way would maybe to plug into 
Nova-conductor for getting Hosts capabilities but that doesn't match yet 
our needs. Comments welcome.

  3/ In order to elect the rights hosts from the freepool (the host 
aggregate where hosts are dedicated to Climate) to the Reservation pool, 
we will implement our own scheduler. Also, duplicate work. It would be 
great ideally if the scheduler could have its own API endpoints so we 
could ask Nova "provide me X hosts with these capabilities and put them 
in this AZ". Comments welcome too.

[1] : 
https://review.openstack.org/#/c/49363/10/climate/db/sqlalchemy/models.py


Thanks,
-Sylvain

>>
>> Climate is planning to reserve both virtual instances and physical 
>> hosts, but for the discussion we had, only physical hosts usecase is 
>> relevant.
>>
>> We had an unconference session today at 2pm, I can share you the 
>> slides :
>>
>> https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p 
>>
>>
>> (please focus on slides 11-14, they're talking on the design for host 
>> reservations)
>>
>> All the code is located on Stackforge, but please note the most 
>> important part of physical host reservations is still under review 
>> there :
>> https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z 
>>
>>
>> (We're missing reviewers, by the way !)
>>
>>
>> I'm open to discuss and waiting your thoughts,
>> -Sylvain
>>
>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/b5b2a4a8/attachment.html>