<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On 4 Apr 2017, at 22:23, Jay Pipes <<a href="mailto:jaypipes@gmail.com" class="">jaypipes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 04/04/2017 02:48 PM, Tim Bell wrote:<br class=""><blockquote type="cite" class="">Some combination of spot/OPIE<br class=""></blockquote><br class="">What is OPIE?<br class=""></div></div></blockquote><div><br class=""></div><div>Maybe I missed a message: I didn’t see any reply to Jay’s question about OPIE.</div><div><br class=""></div><div>OPIE is the OpenStack Preemptible Instances Extension: <a href="https://github.com/indigo-dc/opie" class="">https://github.com/indigo-dc/opie</a></div><div>I am sure other on this list can provide more information.</div><div><br class=""></div><div>I think running OPIE instances inside Blazar reservations would be doable without many changes to the implementation.</div><div>We’ve talked about this idea several times, this forum session would be an ideal place to draw up an implementation plan.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">and Blazar would seem doable as long as the resource provider<br class="">reserves capacity appropriately (i.e. spot resources>>blazar<br class="">committed along with no non-spot requests for the same aggregate).<br class="">Is this feasible?<br class=""></blockquote><br class="">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?<br class=""><br class="">Best,<br class="">-jay<br class=""><br class=""><blockquote type="cite" class="">Tim<br class=""><br class="">On 04.04.17, 19:21, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com" class="">jaypipes@gmail.com</a>> wrote:<br class=""><br class=""> On 04/03/2017 06:07 PM, Blair Bethwaite wrote:<br class=""> > Hi Jay,<br class=""> ><br class=""> > On 4 April 2017 at 00:20, Jay Pipes <<a href="mailto:jaypipes@gmail.com" class="">jaypipes@gmail.com</a>> wrote:<br class=""> >> However, implementing the above in any useful fashion requires that Blazar<br class=""> >> be placed *above* Nova and essentially that the cloud operator turns off<br class=""> >> access to Nova's POST /servers API call for regular users. Because if not,<br class=""> >> the information that Blazar acts upon can be simply circumvented by any user<br class=""> >> at any time.<br class=""> ><br class=""> > That's something of an oversimplification. A reservation system<br class=""> > outside of Nova could manipulate Nova host-aggregates to "cordon off"<br class=""> > infrastructure from on-demand access (I believe Blazar already uses<br class=""> > this approach), and it's not much of a jump to imagine operators being<br class=""> > able to twiddle the available reserved capacity in a finite cloud so<br class=""> > that reserved capacity can be offered to the subset of users/projects<br class=""> > that need (or perhaps have paid for) it.<br class=""><br class=""> Sure, I'm following you up until here.<br class=""><br class=""> > Such a reservation system would even be able to backfill capacity<br class=""> > between reservations. At the end of the reservation the system<br class=""> > cleans-up any remaining instances and preps for the next<br class=""> > reservation.<br class=""><br class=""> By "backfill capacity between reservations", do you mean consume<br class=""> resources on the compute hosts that are "reserved" by this paying<br class=""> customer at some date in the future? i.e. Spot instances that can be<br class=""> killed off as necessary by the reservation system to free resources to<br class=""> meet its reservation schedule?<br class=""><br class=""> > The are a couple of problems with putting this outside of Nova though.<br class=""> > The main issue is that pre-emptible/spot type instances can't be<br class=""> > accommodated within the on-demand cloud capacity.<br class=""><br class=""> Correct. The reservation system needs complete control over a subset of<br class=""> resource providers to be used for these spot instances. It would be like<br class=""> a hotel reservation system being used for a motel where cars could<br class=""> simply pull up to a room with a vacant sign outside the door. The<br class=""> reservation system would never be able to work on accurate data unless<br class=""> some part of the motel's rooms were carved out for reservation system to<br class=""> use and cars to not pull up and take.<br class=""><br class=""> > You could have the<br class=""> > reservation system implementing this feature, but that would then put<br class=""> > other scheduling constraints on the cloud in order to be effective<br class=""> > (e.g., there would need to be automation changing the size of the<br class=""> > on-demand capacity so that the maximum pre-emptible capacity was<br class=""> > always available). The other issue (admittedly minor, but still a<br class=""> > consideration) is that it's another service - personally I'd love to<br class=""> > see Nova support these advanced use-cases directly.<br class=""><br class=""> Welcome to the world of microservices. :)<br class=""><br class=""> -jay<br class=""><br class=""> _______________________________________________<br class=""> OpenStack-operators mailing list<br class=""> <a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.openstack.org</a><br class=""> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br class=""><br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">OpenStack-operators mailing list<br class=""><a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br class=""></div></div></blockquote></div><br class=""></body></html>