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.ba...@bull.net>
To: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org>,
Cc: Mike Spreitzer/Watson/IBM@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
