<div dir="ltr"><p style="margin:0px;font-size:12px;font-family:Helvetica">Hello, everyone!</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica;min-height:14px"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">Patrick, Julien, thank you so much for your comments. As for the moments Patrick mentioned in his letter, I'll describe our vision for them below.</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica;min-height:14px"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">1) Patrick, thank you for the idea! I think it would be great to add not only 'post-lease actions policy', but also 'start-lease actions policy'. I mean like having two types of what can be done with resource (virtual one) on lease starting - 'start VM automatically' or 'start VM manually'. This means user may not use reserved resources at all, if he needs such a behaviour.</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">2) We really believe that creating lease first, and going with its id to all the OpenStack projects to use is a better idea than 'filling' the lease with resources just at the moment of its creation. I'll try to explain why. First of all, as for virtual reservations, we'll need to proxy Nova, Cinder, etc. APIs through Reservation API to reserve VM or volume or something else. Workflow for VM/volume/etc. creation is really complicated and only services written to do this have to do it, in our opinion. Second, this makes adding new reservations to the created lease simple and user friendly. And the last moment, we should not copy all these dashboard pages for instance/volume/... creation to the reservation Dashboard tab in this case. As for the physical reservations, as you mentioned, there is no way to 'create' them like virtual resources in the Nova's, for example, API now. That's why there are two ways to solve this problem and reserve them. First way is to reserve them from Reservation Service as it is implemented now and described also in our document (WF-2b part of it). The second variant (that seems to be more elegant, but more complicated as well) is to implement needed parts as Nova API extension to let Nova do the things it does the best way - managing hosts, VMs, etc. Our concern in this question is not doing things Nova (or any other service) can do much better.</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">3) We completely agree with you! Our 'nested reservation' vision was created only to let user the opportunity of checking reservation status of complex virtual resources (stacks) by having an opportunity to check status of all its 'nested' components, like VMs, networks, etc. This can be done as well by using just Heat without reservation service. Now we are thinking about reservation as the reservation of the OpenStack resource that has ID in the OpenStack service DB, no matter how complex it is (VM, network, floating IP, stack, etc.)</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">4) We were thinking about Reservation Scheduler as a service that controls lease life cycle (starting, ending, making user notifications, etc.) and communicates with Reservation Manager via RPC. Reservation Manager can send user notifications about close lease ending using Ceilometer (this question has to be researched). As for the time needed to run physical reservation or complex virtual one, that is used to make preparations and settings, I think it would be better for user to amortise it in lease using period, because for physical resources it much depends on hardware resources and for virtual ones - on hardware, network and geo location of DCs.</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica;min-height:14px"><br></p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">Thank you,</p>
<p style="margin:0px;font-size:12px;font-family:Helvetica">DIna. </p></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 1:22 PM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 02 2013, Patrick Petit wrote:<br>
<br>
> 3. The proposal specifies that a lease can contain a combo of different<br>
<div class="im">> resources types reservations (instances, volumes, hosts, Heat<br>
> stacks, ...) that can even be nested and that the reservation<br>
> service will somehow orchestrate their deployment when the lease<br>
> kicks in. In my opinion, many use cases (at least ours) do not<br>
> warrant for that level of complexity and so, if that's something<br>
> that is need to support your use cases, then it should be delivered<br>
> as module that can be loaded optionally in the system. Our preferred<br>
> approach is to use Heat for deployment orchestration.<br>
<br>
</div>I agree that this is not something Climate should be in charge. If the<br>
user wants to reserve a set of services and deploys them automatically,<br>
Climate should provide the lease and Heat the deployment orchestration.<br>
Also, for example, it may be good to be able to reserve automatically<br>
the right amount of resources needed to deploy a Heat stack via Climate.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
// Free Software hacker / freelance consultant<br>
// <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</font></span><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>