<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">The biggest concern seemed to be that we weren't sure whether Climate<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">makes sense as an independent project or not. We think it may make more<br></span><span style="font-family:arial,sans-serif;font-size:13px">sense to integrate what Climate does today into Nova directly. More<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">generally, we think reservations of resources may best belong in the<br></span><span style="font-family:arial,sans-serif;font-size:13px">APIs responsible for managing those resources, similar to how quota<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">management for resources lives in the resource APIs.</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">There is some expectation that this type of functionality will extend<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">beyond Nova, but for that we could look at creating a shared library of<br></span><span style="font-family:arial,sans-serif;font-size:13px">code to ease implementing this sort of thing in each API that needs it.</span></blockquote>
<div><br></div>Russel, sure. I guess we'll discuss that more carefully on summit, and I love see that feature implemented in the best way it should be done. I think in person discussion will help here much. I'm hoping to collect more feedback before summit to have multiple view on this problem.<br>
<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I truly agree with the fact that possibly users should not use a separate API for reserving resources, but that would be worth duty for the project itself (Nova, Cinder or even Heat). That said, we think that there is need for having a global ordonancer managing resources and not siloing the resources. Hence that's why we still think there is still a need for a Climate Manager.<br>
Once I said that, there are different ways to plug in with the Manager, our proposal is to deliver a REST API and a python client so that there could be still some operator access for managing the resources if needed. The other way would be to only expose an RPC interface like the scheduler does at the moment but as the move to Pecan/WSME is already close to be done (reviews currently in progress), that's still a good opportunity for leveraging the existing bits of code.</blockquote>
</div><div><br></div><div>Sylvain, I quite agree with you.</div><div><br></div><div>-- Dina</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 8:14 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@gmail.com" target="_blank">sylvain.bauza@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Russell,<div>Thanks for replying,</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-12 16:46 GMT+01:00 Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span>:<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 03/12/2014 07:35 AM, Dina Belova wrote:<br>
> Thanks TC for spending time on Blazar (ex. Climate, in process of<br>
> renaming) discussion!<br>
><br>
> It was decided that potentially reservation idea is interesting for OS<br>
> and it'll be great to have cross-project session on ongoing Atlanta<br>
> Summit and discuss future of reservation/scheduling management in OpenStack.<br>
><br>
> Here is link to cross-project session proposal:<br>
><br>
> <a href="http://summit.openstack.org/cfp/details/45" target="_blank">http://summit.openstack.org/cfp/details/45</a><br>
><br>
> Thanks everyone and let's keep working on that idea.<br>
<br>
</div>Yes, I do think it would be useful to discuss this in person. However,<br>
I don't think that was the most important feedback from the TC meeting.<br>
<br>
The biggest concern seemed to be that we weren't sure whether Climate<br>
makes sense as an independent project or not. We think it may make more<br>
sense to integrate what Climate does today into Nova directly. More<br>
generally, we think reservations of resources may best belong in the<br>
APIs responsible for managing those resources, similar to how quota<br>
management for resources lives in the resource APIs.<br>
<br>
There is some expectation that this type of functionality will extend<br>
beyond Nova, but for that we could look at creating a shared library of<br>
code to ease implementing this sort of thing in each API that needs it.<br></blockquote><div><br></div><div><br></div></div><div>That's really a good question, so maybe I could give some feedback on how we deal with the existing use-cases.</div>
<div>About the possible integration with Nova, that's already something we did for the virtual instances use-case, thanks to an API extension responsible for checking if a scheduler hint called 'reservation' was spent, and if so, take use of the python-climateclient package to send a request to Climate.</div>
<div><br></div><div>I truly agree with the fact that possibly users should not use a separate API for reserving resources, but that would be worth duty for the project itself (Nova, Cinder or even Heat). That said, we think that there is need for having a global ordonancer managing resources and not siloing the resources. Hence that's why we still think there is still a need for a Climate Manager.</div>
<div><br></div><div>Once I said that, there are different ways to plug in with the Manager, our proposal is to deliver a REST API and a python client so that there could be still some operator access for managing the resources if needed. The other way would be to only expose an RPC interface like the scheduler does at the moment but as the move to Pecan/WSME is already close to be done (reviews currently in progress), that's still a good opportunity for leveraging the existing bits of code.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-Sylvain</div><div> </div></font></span></div></div></div>
<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>