Open Stack

On Tue, Jul 8, 2014 at 4:18 AM, Lisa <lisa.zangrando at pd.infn.it> wrote:

>  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.zangrando at 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 think you can adapt your model your use case to the spot instance model
by allocating different groups 'money' instead of a pre-defined share. If
one user tries to use more then there share they will run out of 'money.'
 Would that fully align the two models?

Also why pre-define the different life times for type 3 instances?



>
>
>
> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140708/efb90de6/attachment.html>