Open Stack

Hi Mike,

Dina and you outlined some differences in terms of seeing what is 
dependent on what.
As Dina explained, Climate plans to be integrated into Nova and Heat 
logics, where Heat and Nova would request Climate API by asking for a 
lease and would tag on their own the resources as 'RESERVED'.
On your point, and correct me if I'm wrong, you would rather see Climate 
on top of Heat and Nova, scheduling resources on its own, and only send 
creation requests to Heat and Nova.

I'm happy to say both of you are right : Climate aims to be both called 
by Nova and *also* calling Nova. That's just matter of what Climate 
*is*. And here is the confusion.

That's why Climate is not only one API endpoint. It actually have two 
distinct endpoints : one called the Lease API endpoint, and one called 
the Resource Reservation API endpoint.

As a Climate developer working on physical hosts reservations (and not 
Heat stacks), my concern is to be able to guarantee to a REST client 
(either a user or another service) that if this user wants to provision 
X hosts on a specific timeframe in the future (immediate or in 10 
years), Climate will be able to provision them. By meaning "being able" 
and "guarantee", I do use strong words for stating that we engage 
ourselves to be able to plan what will be resources capacity state in 
the future.

This decision-making process (ie. this "Climate scheduler") will be 
implemented as RPC Service for the Reservation API, and thus will needs 
to keep its own persistence layer in Climate. Of course, it will request 
the Lease API for really creating the lease and managing lease start/end 
hooks, that's the Lease API job.


Provided you would want to use the Reservation API for "reserving" Heat 
stacks, you would have to implement it tho.


Thanks,
-Sylvain

Le 06/10/2013 20:41, Mike Spreitzer a écrit :
> Thanks, Dina.  Yes, we do not understand each other; can I ask some 
> more questions?
>
> You outlined a two-step reservation process ("We assume the following 
> reservation process for the OpenStack services..."), and right after 
> that talked about changing your mind to use Heat instead of individual 
> services.  So I am confused, I am not sure which of your remarks 
> reflect your current thinking and which reflect old thinking.  Can you 
> just state your current thinking?
>
> On what basis would Climate decide to start or stop a lease?  What 
> sort of event notifications would Climate be sending, and when and 
> why, and what would subscribers do upon receipt of such notifications?
>
> If the individual resource services continue to make independent 
> scheduling decisions as they do today, what value does Climate add?
>
> Maybe a little more detailed outline of what happens in your current 
> thinking, in support of an explicitly stated use case that shows the 
> value, would help here.
>
> Thanks,
> Mike
>
>
> _______________________________________________
> 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/20131007/c7e5ed31/attachment.html>