<div dir="ltr"><div>Hello, Mike!</div><div><br></div><div>As for Nova connected thoughts, it was just a reference to the Roadmap, that includes implementing the reservations opportunity first of all for the solid virtual resources (VMs, volumes, …) and next for the complex ones (Heat stacks, Savanna clusters, …). To implement complex reservations we need implementation of the simple ones.</div>
<div><br></div><div>Climate will be the independent service, that will the the underlaying layer for other OpenStack services wishing not just start some virtual resource, but reserve it for the future with different policies.</div>
<div><br></div><div>We assume the following reservation process for the OpenStack services:</div><div><span class="" style="white-space:pre">     </span>1) User goes to service and and does all actions as usual only passing his/her wish to reserve resource, not really start it.</div>
<div><span class="" style="white-space:pre">    </span>2) Service does all the usual actions, but not really starts resource. Instead of that is uses Climate to create lease and then Climate decides what events should happen to the lease - start, end, send notification about some event and so on.</div>
<div><br></div><div>We were thinking about leases of resources from different services for the first time, but here we found some logical problem - nobody really needs just VM, just volume and just floating IP. To work together, volume should be attached to VM and IP should be assigned too. But this is just the thing that Heat does. That's why now we are thinking of lease as reserving the resources from one service - to reserve VM+volume+IP using Heat will be the better idea I suppose.</div>
<div><br></div><div>As for scheduling part, in our current scheme we'll use services' schedulers cause now they do their work in the best way. That's why Climate now looks as the underlaying service, not the upper one. That way provides the opportunity to use all capabilities of existing services and do not proxy all the resource-creation preparations and calls when user really ants to reserve something.</div>
<div><br></div><div>Also I think we do not really understand each other in the question of how any OpenStack service and Climate may use each other. We were thinking that any service goes to Climate to create lease with already existing resources IDs in services' DB. In Nova case it looks like Nova schedules VM, creates in DB instance with the 'RESERVED' status and then sends Climate lease creation request. And then Climate uses its internal schedule to do all the actions with that resource defined by plugin for the lease start/end. In this view nobody except Climate really owns lease with all the reservations. But I see you have some other view on how that process may look like. Although it was not the idea we were thinking about for the Climate.</div>
<div><br></div><div>As for we were thinking about service->Climate workflow, service already will mark 'RESERVED' resource in its DB when it'll send lease creation request to the Climate. That's why that backing capacity will be already used by service and mentioned in the further scheduling process.</div>
<div><br></div><div>Now we'll reserve resource right at the moment of lease creation, that means it's more useful for the not so far future. But also we are thinking to implement the opportunity of  not only the immediate resources reservation, but that is questionable.</div>
<div><br></div><div>Thank you,</div><div>Dina</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Oct 6, 2013 at 10:36 AM, Mike Spreitzer <span dir="ltr"><<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">I looked at the blueprint (</font><a href="https://blueprints.launchpad.net/heat/+spec/stacks-reservation" target="_blank"><font face="sans-serif">https://blueprints.launchpad.net/heat/+spec/stacks-reservation</font></a><font face="sans-serif">)
and associated wiki page (</font><a href="https://wiki.openstack.org/wiki/Heat/Reservation" target="_blank"><font face="sans-serif">https://wiki.openstack.org/wiki/Heat/Reservation</font></a><font face="sans-serif">),
and I have a few comments/questions.</font>
<br>
<br><font face="sans-serif">The wiki page has some remarks that
are Nova-centric, and some other remarks that emphasize that Climate is
not just about Nova, and I do not understand the relationship between these
remarks.  Is this a roadmapping thought (start with just Nova, expand
to other services later), or the inclusion of some details (related to
Nova) and omission of other similar details (related to the other services),
or what?</font>
<br>
<br><font face="sans-serif">Will Climate be an independent service,
or part of Nova, or what?</font>
<br>
<br><font face="sans-serif">What will be the atomic operations?
 I presume the primary interesting operation will be something like
reserving a bag of resources, where that bag is allowed to contain any
mixture of resources from any services.  Have I got that right?</font>
<br>
<br><font face="sans-serif">What exactly does reserving a resource
mean?  Does this atomic reservation operation include some atomic
cooperation from the resources' services' schedulers (e.g., Nova scheduler,
Cinder scheduler, etc)?  Or is this reservation service logically
independent of the resources' primary schedulers?  Overall I am getting
the suggestion that reservation is an independent service.  The flow
is something like first reserve a bag of resources, and then proceed to
use them at your leisure.  But I also suppose that the important thing
about a reservation is that it includes the result of scheduling (placement)
--- the point of a reservation is that it is holding capacity to host the
reserved resources.  You do not want an atomic operation to take a
long time; do the scheduling decisions get made (tentatively, of course)
before the real atomic section, with re-schedule and re-try on conflict
detection, or is scheduling included in the atomic section?</font>
<br>
<br><font face="sans-serif">For how long does a reservation last?
 What sort of thing owns a reservation?  I suppose one important
use case is that a heat engine, or the heat service (in the multi-engine
world), could own a reservation; in this use case, the reservation would
last until heat releases it.  Hopefully heat will persist its reservation
information, so that a process crash will not cause a dangling reservation;
how will you enable complete avoidance of timing splinters (e.g., heat
engine crashes after making reservation but before persisting information
about it)?  Presumably other things besides heat could own reservations.</font>
<br>
<br><font face="sans-serif">Is this primarily about planning for
the distant future, or focused on the immediate future?  If a bag
of resources (including their backing capacities) is reserved for a period
that starts more than a little while in the future, what is done with that
backing capacity in the meantime?</font>
<br>
<br><font face="sans-serif">I see use cases for immediate future
reservations; do you have use cases for more distant reservations?</font>
<br>
<br><font face="sans-serif">Thanks,</font>
<br><font face="sans-serif">Mike</font><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><p style="font-size:small;margin:0px;font-family:Helvetica">
Best regards,</p><p style="font-size:small;margin:0px;font-family:Helvetica">Dina Belova</p><p style="font-size:small;margin:0px;font-family:Helvetica">Software Engineer</p><p style="font-size:small;margin:0px;font-family:Helvetica">
Mirantis Inc.</p></div></div>
</div>