<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>