<p dir="ltr">Hi Tim,</p>
<p dir="ltr">Thanks for initiating this discussion...</p>
<p dir="ltr">On 9 June 2016 at 15:28, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
> Sorry I was not able to make it. To clarify on Blazar for CERN (<a href="http://eavesdrop.openstack.org/meetings/scientific_wg/2016/scientific_wg.2016-06-08-06.59.log.html">http://eavesdrop.openstack.org/meetings/scientific_wg/2016/scientific_wg.2016-06-08-06.59.log.html</a>), 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> There seem to be a variety of approaches from pre-emptible VMs (<a href="https://github.com/indigo-dc/opie">https://github.com/indigo-dc/opie</a>) 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.</p>
<p dir="ltr">Do you have a reference for Symphony?</p>
<p dir="ltr">> Overall, we are trying to find a way to ensure the cloud is<br>
><br>
> - Always busy by using any additional resources available for low SLA activities<br>
> - Elastic by using the low SLA resources as a buffer</p>
<p dir="ltr">I like this, a very succinct description of motivation!</p>
<p dir="ltr">> 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).<br>
><br>
> I’d be very interested to hear how others see this problem.</p>
<p dir="ltr">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?!</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">-- <br>
Cheers,<br>
~Blairo</p>