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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
