Open Stack

Hi Tim,

Thanks for initiating this discussion...

On 9 June 2016 at 15:28, Tim Bell <Tim.Bell at cern.ch> wrote:
> Sorry I was not able to make it. To clarify on Blazar for CERN (
http://eavesdrop.openstack.org/meetings/scientific_wg/2016/scientific_wg.2016-06-08-06.59.log.html),
we’re interested in the overall problem of how to maximize the utilization
of the resources in the private cloud rather than a specific project at the
moment.

I think that's likely to be the motivation for the majority of others too.
Chameleon has quite a special function so they would naturally be less
concerned about overall utilisation - the utilisation of the scientist's
time is more important than that of the testbed.

> There seem to be a variety of approaches from pre-emptible VMs (
https://github.com/indigo-dc/opie) to a cloud aware scheduler with a queue
(i.e. do not return No Host Found but wait and retry) such as Symphony or
some of the ongoing work with HTCondor.

Do you have a reference for Symphony?

> Overall, we are trying to find a way to ensure the cloud is
>
> - Always busy by using any additional resources available for low SLA
activities
> - Elastic by using the low SLA resources as a buffer

I like this, a very succinct description of motivation!

> Blazar may be a base to build this functionality on but my current
understanding is that the reservations are somewhat static (i.e. reserve me
X instances at time Y).
>
> I’d be very interested to hear how others see this problem.

>From our discussion in the meeting it sounds as though Blazar could be
trivially altered to support preemptible instances that could backfill
Blazar leases. I think you'd have set of specific low-SLA flavors tied to
the base aggregate that Blazar uses on hosts with no active reservations.
Blazar would need to be modified to find and delete instances of those
types when starting a lease. No doubt this is glossing over a lot, but in
the whole host mode that Chameleon is using it seems quite plausible.
Wouldn't it be nice if Chameleon nodes were open for elastic compute
workloads when not reserved?!

The problem with the above idea though, is that you still have to segregate
on-demand and reserved infrastructure, and of course it assumes you even
want reserved infrastructure in the first place.

We're also not talking about a spot market here, it's still first come
first served. But that might be OK for Science Clouds, you'd limit the
access to the preemptible flavors anyway.

-- 
Cheers,
~Blairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20160609/32142edc/attachment.html>