Open Stack

Hi Tim,

It does seem feasible, but imagine the aggregate juggling... it's
something of an indictment that from where we are today this seems
like a step forward. I'm not a fan of pushing that load onto operators
when it seems like what we actually need is fully-fledged workload
scheduling in Nova.

Cheers,

On 5 April 2017 at 04:48, Tim Bell <Tim.Bell at cern.ch> wrote:
> Some combination of spot/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?
>
> 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
>
>



-- 
Cheers,
~Blairo