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.b...@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" <jaypi...@gmail.com> wrote: > > On 04/03/2017 06:07 PM, Blair Bethwaite wrote: > > Hi Jay, > > > > On 4 April 2017 at 00:20, Jay Pipes <jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Cheers, ~Blairo _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
