Hi Sylvain,
On 08/07/2014 09:29, Sylvain Bauza wrote:
Le 08/07/2014 00:35, Joe Gordon a écrit :
On Jul 7, 2014 9:50 AM, "Lisa" <lisa.zangra...@pd.infn.it
<mailto:lisa.zangra...@pd.infn.it>> wrote:
>
> Hi all,
>
> 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.
> Any comment and feedback is welcome.
The attached document was very helpful, than you.
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.
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.
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).
Instead, in Amazon, the spot instance is released whenever the spot
price rises.
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.
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
https://wiki.openstack.org/wiki/Blazar#Lease_types_.28concepts.29 )
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 ?
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).
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.
Just few questions. We read your use cases and it seems you had some
issues with the quota handling. How did you solved it?
About the Blazar's architecture
(https://wiki.openstack.org/w/images/c/cb/Climate_architecture.png): the
resource plug-in interacts even with the nova-scheduler?
Such scheduler has been (or will be) extended for supporting the
Blazar's requests?
Which relationship there is between nova-scheduler and Gantt?
It would be nice to discuss with you in details.
Thanks a lot for your feedback.
Cheers,
Lisa
Thanks,
-Sylvain
> Thanks a lot.
> Cheers,
> Lisa
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
