<div dir="ltr"><div>Russell, first of all thanks for your opinion and taking part in this discussion.</div><div><br></div><div>> What we need to dig in to is *why* do you feel it needs to be global?</div><div>></div>
<div>> I'm trying to understand what you're saying here ... do you mean that</div><div>> since we're trying to get to where there's a global scheduler, that it</div><div>> makes sense there should be a central point for this, even if the API is</div>
<div>> through the existing compute/networking/storage APIs?</div><div>> </div><div>> If so, I think that makes sense. However, until we actually have</div><div>> something for scheduling, I think we should look at implementing all of</div>
<div>> this in the services, and perhaps share some code with a Python library.</div><div><br></div><div>Well, let me give you some reasons I’m thinking about speaking about separated service with its own endpoints, etc.</div>
<div><br></div><div>* as you said, we propose different resources reservations to be implemented for OS, and compute resources (VMs and hosts) are not only ones for that;</div><div>* there should be support of time management, checking leases statuses, sending user notifications, etc. - even if that’ll be implemented as library, it’ll need separately running service in Nova, because there will be some specific periodic tasks and so on. Of course, that might be part of nova-scheduler, but in this case such things as sending notifications will look strange here - and that will allow to manage only VMs, not hosts, at least if we are speaking about traditional Nova scheduling process;</div>
<div>* and the last: previous points might be implemented as some library, and work ok, I quite agree with you here. Although in this case there will be no centralised point of leases management, as there is no one point for quotas management now. And if for quotas that’s uncomfortable to manage them in case of huge clouds, for leases it will be simply impossible to have one picture of what will be going with all resources in future - as there are many things to keep track on - compute capacity, storage capacity, etc.</div>
<div><br></div><div>The last point seems most important for me, as the idea of centralised resource time management looks better for me than idea of each service having simply the same code working on its own reservation, plus the fact we consider that some scheduling dependencies could happen with heterogenous resources like reserving a volume with an instance booting on it. I quite agree that for user it’ll be more comfortable to use services as is, and as Sylvain said, that might implemented quite nice due to, for example, Nova extensions (as it’s done now for VM reservations). But at the same moment all logic related to leases will be in one place, allowing cloud administrators manage cloud capacity usage in time from one place.</div>
<div><br></div><div>And I’m not talking about additional load to core reviewers of all projects in case of implementing that feature in every single project, although there is already existing team on Climate. That’s not the main thing.</div>
<div><br></div><div>As said that’s my personal opinion, and I’ll be really glad to discuss this problem and solve it in the best way chosen by community with taking into account different points of view and ideas.</div><div>
<br></div><div>Thanks</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 6:44 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 03/12/2014 12:14 PM, Sylvain Bauza wrote:<br>
> Hi Russell,<br>
> Thanks for replying,<br>
><br>
><br>
> 2014-03-12 16:46 GMT+01:00 Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><br>
</div>> <mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>>:<br>
<div class="">> 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>
><br>
><br>
><br>
> That's really a good question, so maybe I could give some feedback on<br>
> how we deal with the existing use-cases.<br>
> About the possible integration with Nova, that's already something we<br>
> did for the virtual instances use-case, thanks to an API extension<br>
> responsible for checking if a scheduler hint called 'reservation' was<br>
> spent, and if so, take use of the python-climateclient package to send a<br>
> request to Climate.<br>
><br>
> I truly agree with the fact that possibly users should not use a<br>
> separate API for reserving resources, but that would be worth duty for<br>
> the project itself (Nova, Cinder or even Heat). That said, we think that<br>
> there is need for having a global ordonancer managing resources and not<br>
> siloing the resources. Hence that's why we still think there is still a<br>
> need for a Climate Manager.<br>
<br>
</div>What we need to dig in to is *why* do you feel it needs to be global?<br>
<br>
I'm trying to understand what you're saying here ... do you mean that<br>
since we're trying to get to where there's a global scheduler, that it<br>
makes sense there should be a central point for this, even if the API is<br>
through the existing compute/networking/storage APIs?<br>
<br>
If so, I think that makes sense. However, until we actually have<br>
something for scheduling, I think we should look at implementing all of<br>
this in the services, and perhaps share some code with a Python library.<br>
So, I'm thinking along the lines of ...<br>
<br>
1) Take what Climate does today and work to integrate it into Nova,<br>
using as much of the existing Climate code as makes sense. Be careful<br>
about coupling in Nova so that we can easily split out the right code<br>
into a library once we're ready to work on integration in another project.<br>
<br>
2) In parallel, continue working on decoupling nova-scheduler from the<br>
rest of Nova, so that we can split it out into its own project.<br>
<br>
3) Once the scheduler is split out, re-visit what part of reservations<br>
functionality belongs in the new scheduling project and what parts<br>
should remain in each of the projects responsible for managing resources.<br>
<div class=""><br>
> Once I said that, there are different ways to plug in with the Manager,<br>
> our proposal is to deliver a REST API and a python client so that there<br>
> could be still some operator access for managing the resources if<br>
> needed. The other way would be to only expose an RPC interface like the<br>
> scheduler does at the moment but as the move to Pecan/WSME is already<br>
> close to be done (reviews currently in progress), that's still a good<br>
> opportunity for leveraging the existing bits of code.<br>
<br>
</div>Yes, I would want to use as much of the existing code as possible.<br>
<br>
As I said above, I just think it's premature to make this its own<br>
project on its own, unless we're able to look at scheduling more broadly<br>
as its own project.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Russell Bryant<br>
<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>
</div></div></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>