<div dir="ltr">Hi Phill,<div><br></div><div>Sylvain has described almost everything about Climate :) And as he said first time, idea for using Pclouds came to Climate because of reserving of compute nodes. And now for our first release we're preparing two types of reservations:</div>

<div><br></div><div>1) compute node reservation</div><div>2) virtual instance reservation</div><div><br></div><div>Sure, Nova manages now both of these resources, but idea of Climate is not about only these reservation types. We're thinking about global Reservation-as-a-Service thing that will have opportunity of reserving other types of OS resources. They might be Cinder volumes, Neutron network resources, complex virtual resources (like Heat stacks and Savanna clusters). As for physical reservations, there can be reserved storage nodes, not only compute ones.</div>

<div><br></div><div>That's why we truly believe it's a great idea for new OS ecosystem service - Climate, that will manage any reservation needs users and cloud providers have.</div><div><br></div><div>Thanks</div>
<div>Dina</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 5:20 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@bull.net" target="_blank">sylvain.bauza@bull.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Phil,<br>
<br>
Le 21/01/2014 13:13, Day, Phil a écrit :<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Phil and Jay,<br>
<br>
Phil, maybe you remember I discussed with you about the possibility of using pclouds with Climate, but we finally ended up using Nova aggregates and a dedicated filter.<br>
That works pretty fine. We don't use instance_properties<br>
but rather aggregate metadata but the idea remains the same for isolation.<br>
</blockquote>
Sure do, and I had a question around that which has been buzzing in my head for a while now.<br>
<br>
I can see how you can use an aggregate as a way of isolating the capacity of some specific hosts (Pclouds was pretty much doing the same thing - it was in effect an abstraction layer to surface aggregates to users), and I can see that you can then plan how to use that capacity against a list of reservations.<br>

<br>
It does though seem that you're confined to working on some subset of the physical hosts, which I'd of thought could become quite restrictive in some cases and hard to optimize for capacity.  (if for example a user wants to combine reservations with anti-affinity then you'd need to have a larger pool of hosts to work with).<br>

</blockquote>
<br></div>
My bad, documentation is missing for Climate and that's something we plan to deliver right after the 0.1 release arriving this week. Should you have found documentation for this, you would have seen that Climate is not only focusing about compute hosts reservations, but rather plans to deliver any Openstack object (virtual instances and compute hosts that are implemented for the 0.1 release, or virtual Neutron routers or Heat stack - to be planned)<br>

<br>
The current implementation for compute hosts is done using aggregates, but that's not the case for virtual instances. Even that said, thanks to your previous email, I'm thinking about the way getting rid of managing host aggregates, but rather use hosts directly with possible tagging to the scheduler. That's still unclear in my mind, but that would have the good benefit of removing what we call 'freepool', ie. hosts dedicated to Climate.<br>

In order to ensure capacity planning and be able to certify that Climate would be able to cope with the reservation asked in the future, one possible way would be to say "let's define that we will dedicate up to X percents of our compute hosts to Climate, whatever the compute hosts are, and be intelligent for selecting the hosts".<br>

Such that way, there is no problem mixing both anti-affinity filter and Climate filter.<br>
<br>
Again, keep in mind Climate scopes to provide reservations not only for hosts, but also instances, etc.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It sort of feels to me that a significant missing of having a reservation system for Nova is that there is no matching concept within Nova of the opposite of a reservation - a spot instance (i.e an instance which the user gets for a lower price in return for knowing it can be deleted by the system if the capacity is needed for another higher-priority request - e.g. a reservation).<br>

<br>
If we had a concept of spot instances in Nova, and the corresponding process to remove them, then the capacity demands of reservations could be balanced by the amount of spot-instance usage in the system (and this would seem a good role for an external controller).<br>

</blockquote></div>
Here, you mix two different Climate concerns : instances and hosts. We already define in Climate what we call 'best-effort' lease, ie. a non-certified lease for Climate because of non-matching requirements (for example, say a user wants 5 hosts while Climate only can give him 4, if the lease would be 'best-effort', Climate would create the lease with 4 hosts instead of 5, while a "normal" lease would be denied by Climate). Once the hosts are here, the user can boot as many instances as he wants.<br>

<br>
The virtual instances plugin is also another possible use : provided you want to provision an instance for a certain amount of time, Nova will shelve it upon creation, Climate will unshelve it when the lease start and Climate will destroy it at the lease end.<br>

<br>
<br>
These both plugins (virtual instances plugin and compute hosts plugin) need to define what we call a termination statement : what to do when the lease ends ? With compute hosts, if instances are still running, should we kill them, or leave them and not put back the host in the freepool ? All these behaviors should be configuration-driven, so that the admin would have the choice.<br>

<br>
A spot instance in such our system would be the fact that we allow Climate to free up the resources (kill it or whatever) before the lease ends, that's another scenario but possible.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm wondering if managing spot instances and reservations across the whole of a Nova system wouldn't be a more general use case than having to manage this within a specific aggregate - or am I missing something ?<br>

</blockquote></div>
The main point is that you want to potentially provision other objects than just instances or hosts, like Cinder volumes. That's why we think reservations need to be managed by a separate Openstack service. That said, we personnally think Climate and Nova can interact, at least about tenancy isolation or scheduling of hosts (but that's Gantt's scope), and I would be glad to help providing Nova such missing things.<span class="HOEnZb"><font color="#888888"><br>

<br>
-Sylvain</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Phil<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>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>