[Openstack-operators] [scientific] Resource reservation requirements (Blazar) - Forum session

Jay Pipes jaypipes at gmail.com
Tue Apr 4 21:23:03 UTC 2017

On 04/04/2017 02:48 PM, Tim Bell wrote:
> Some combination of spot/OPIE

What is OPIE?

> and Blazar would seem doable as long as the resource provider
> reserves capacity appropriately (i.e. spot resources>>blazar
> committed along with no non-spot requests for the same aggregate).
> Is this feasible?

I'm not sure how the above is different from the constraints I mention 
below about having separate sets of resource providers for preemptible 
instances than for non-preemptible instances?


> Tim
> On 04.04.17, 19:21, "Jay Pipes" <jaypipes at gmail.com> wrote:
>     On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
>     > Hi Jay,
>     >
>     > On 4 April 2017 at 00:20, Jay Pipes <jaypipes at gmail.com> wrote:
>     >> However, implementing the above in any useful fashion requires that Blazar
>     >> be placed *above* Nova and essentially that the cloud operator turns off
>     >> access to Nova's  POST /servers API call for regular users. Because if not,
>     >> the information that Blazar acts upon can be simply circumvented by any user
>     >> at any time.
>     >
>     > That's something of an oversimplification. A reservation system
>     > outside of Nova could manipulate Nova host-aggregates to "cordon off"
>     > infrastructure from on-demand access (I believe Blazar already uses
>     > this approach), and it's not much of a jump to imagine operators being
>     > able to twiddle the available reserved capacity in a finite cloud so
>     > that reserved capacity can be offered to the subset of users/projects
>     > that need (or perhaps have paid for) it.
>     Sure, I'm following you up until here.
>     > Such a reservation system would even be able to backfill capacity
>     > between reservations. At the end of the reservation the system
>     > cleans-up any remaining instances and preps for the next
>     > reservation.
>     By "backfill capacity between reservations", do you mean consume
>     resources on the compute hosts that are "reserved" by this paying
>     customer at some date in the future? i.e. Spot instances that can be
>     killed off as necessary by the reservation system to free resources to
>     meet its reservation schedule?
>     > The are a couple of problems with putting this outside of Nova though.
>     > The main issue is that pre-emptible/spot type instances can't be
>     > accommodated within the on-demand cloud capacity.
>     Correct. The reservation system needs complete control over a subset of
>     resource providers to be used for these spot instances. It would be like
>     a hotel reservation system being used for a motel where cars could
>     simply pull up to a room with a vacant sign outside the door. The
>     reservation system would never be able to work on accurate data unless
>     some part of the motel's rooms were carved out for reservation system to
>     use and cars to not pull up and take.
>      >  You could have the
>     > reservation system implementing this feature, but that would then put
>     > other scheduling constraints on the cloud in order to be effective
>     > (e.g., there would need to be automation changing the size of the
>     > on-demand capacity so that the maximum pre-emptible capacity was
>     > always available). The other issue (admittedly minor, but still a
>     > consideration) is that it's another service - personally I'd love to
>     > see Nova support these advanced use-cases directly.
>     Welcome to the world of microservices. :)
>     -jay
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

More information about the OpenStack-operators mailing list