<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 6:55 AM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@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 bgcolor="#FFFFFF" text="#000000">
<div>Le 08/07/2014 13:18, Lisa a écrit :<br>
</div><div class="">
<blockquote type="cite">
<div>Hi Sylvain,<br>
<br>
On 08/07/2014 09:29, Sylvain Bauza wrote:<br>
</div>
<blockquote type="cite">
<div>Le 08/07/2014 00:35, Joe Gordon a
écrit :<br>
</div>
<blockquote type="cite">
<p dir="ltr"><br>
On Jul 7, 2014 9:50 AM, "Lisa" <<a href="mailto:lisa.zangrando@pd.infn.it" target="_blank">lisa.zangrando@pd.infn.it</a>>
wrote:<br>
><br>
> Hi all,<br>
><br>
> during the last IRC meeting, for better understanding
our proposal (i.e the FairShareScheduler), you suggested us
to provide (for the tomorrow meeting) a document which fully
describes our use cases. Such document is attached to this
e-mail.<br>
> Any comment and feedback is welcome.</p>
<p dir="ltr">The attached document was very helpful, than you.</p>
<p dir="ltr">It sounds like Amazon's concept of spot instances
( as a user facing abstraction) would solve your use case in
its entirety. I see spot instances as the general solution
to the question of how to keep a cloud at full utilization.
If so then perhaps we can refocus this discussion on the
best way for Openstack to support Amazon style spot
instances.</p>
</blockquote>
<br>
<br>
<br>
Can't agree more. Thanks Lisa for your use-cases, really helpful
for understand your concerns which are really HPC-based. If we
want to translate what you call Type 3 in a non-HPC world where
users could compete for a resource, spot instances model is
coming to me as a clear model.<br>
</blockquote>
<br>
our model is similar to the Amazon's spot instances model because
both try to maximize the resource utilization. The main difference
is the mechanism used for assigning resources to the users (the
user's offer in terms of money vs the user's share). They differ
even on how they release the allocated resources. In our model,
the user, whenever requires the creation of a Type 3 VM, she has
to select one of the possible types of "life time" (short = 4
hours, medium = 24 hours, long = 48 hours). When the time expires,
the VM is automatically released (if not explicitly released by
the user).<br>
Instead, in Amazon, the spot instance is released whenever the
spot price rises.<br>
<br>
</blockquote>
<br>
<br></div>
That's just another trigger so the model is still good for defining
what you say "Type 3" :-)<div class=""><br>
<br>
<blockquote type="cite"> <br>
<blockquote type="cite"> <br>
I can see that you mention Blazar in your paper, and I
appreciate this. Climate (because that's the former and better
known name) has been kick-off because of such a rationale that
you mention : we need to define a contract (call it SLA if you
wish) in between the user and the platform.<br>
And you probably missed it, because I was probably unclear when
we discussed, but the final goal for Climate is *not* to have a
start_date and an end_date, but just *provide a contract in
between the user and the platform* (see <a href="https://wiki.openstack.org/wiki/Blazar#Lease_types_.28concepts.29" target="_blank">https://wiki.openstack.org/wiki/Blazar#Lease_types_.28concepts.29</a>
)<br>
<br>
Defining spot instances in OpenStack is a running question, each
time discussed when we presented Climate (now Blazar) at the
Summits : what is Climate? Is it something planning to provide
spot instances ? Can Climate provide spot instances ?<br>
<br>
I'm not saying that Climate (now Blazar) would be the only
project involved for managing spot instances. By looking at a
draft a couple of months before, I thought that this scenario
would possibly involve Climate for best-effort leases (see again
the Lease concepts in the wiki above), but also the Nova
scheduler (for accounting the lease requests) and probably
Ceilometer (for the auditing and metering side).<br>
<br>
Blazar is now in a turn where we're missing contributors because
we are a Stackforge project, so we work with a minimal bandwidth
and we don't have time for implementing best-effort leases but
maybe that's something we could discuss. If you're willing to
contribute to an Openstack-style project, I'm personnally
thinking Blazar is a good one because of its little complexity
as of now.<br></blockquote></blockquote></div></div></blockquote><div><br></div><div><br></div><div>I think the current thinking around how to sport spot instances is somewhat backwards. We should first identify the user facing requirements (I.E. API changes) then identify the missing pieces needed to support that API, and lastly figure out where those missing pieces should live. I don't think we can say Blazer is the answer without fully understanding the problem.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class=""><blockquote type="cite"><blockquote type="cite">
<br>
</blockquote>
<br>
<br>
Just few questions. We read your use cases and it seems you had
some issues with the quota handling. How did you solved it?<br>
About the Blazar's architecture (<a href="https://wiki.openstack.org/w/images/c/cb/Climate_architecture.png" target="_blank">https://wiki.openstack.org/w/images/c/cb/Climate_architecture.png</a>):
the resource plug-in interacts even with the nova-scheduler?<br>
Such scheduler has been (or will be) extended for supporting the
Blazar's requests?<br>
Which relationship there is between nova-scheduler and Gantt?<br>
<br>
It would be nice to discuss with you in details.<br>
Thanks a lot for your feedback.<br>
Cheers,<br>
Lisa<br>
<br>
</blockquote>
<br></div>
As said above, there are still some identified lacks in Blazar, but
we miss resources for implementing these. Quotas is one of them, but
some people in Yahoo! expressed their interest in Climate for
implementing deferred quotas, so it could be done in the next cycle.<br>
<br>
As nova-scheduler is not enduser-facing (no API), we're driving a
call to nova-api for placing resources thanks to aggregates. That's
also why we're looking at Gantt, because it would be less tricky for
doing this.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-Sylvain</font></span><div class=""><br>
<br>
<blockquote type="cite"> <br>
<br>
<blockquote type="cite"> <br>
Thanks,<br>
-Sylvain<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<p dir="ltr">> Thanks a lot.<br>
> Cheers,<br>
> Lisa<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</p>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</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></div></div>