Open Stack

Do not worry about what I want, right now I am just trying to understand 
the Climate proposal, wrt virtual resources (Patrick helped a lot on the 
physical side).  Can you please walk through a scenario involving Climate 
reservations on virtual resources?  I mean from start to finish, outlining 

which party makes which decision, based on what.

Thanks,
Mike



From:   Sylvain Bauza <sylvain.bauza at bull.net>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Cc:     Mike Spreitzer/Watson/IBM at IBMUS
Date:   10/07/2013 05:07 AM
Subject:        Re: [openstack-dev] [Climate] Questions and comments



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/b6e1c065/attachment.html>