On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague <s...@dague.net> wrote: > On 03/03/2014 01:35 PM, Joe Gordon wrote: >> On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter <zbit...@redhat.com> wrote: >>> On 03/03/14 12:32, Joe Gordon wrote: >>>>> >>>>>> - if you're reserving resources far before you'll need them, it'll be >>>>>> cheaper >>>> >>>> Why? How does this save a provider money? >>> >>> >>> If an operator has zero information about the level of future demand, they >>> will have to spend a *lot* of money on excess capacity or risk running out. >>> If an operator has perfect information about future demand, then they need >>> spend no money on excess capacity. Everywhere in between, the amount of >>> extra money they need to spend is a non-increasing function of the amount of >>> information they have. QED. >> >> Sure. if an operator has perfect information about future demand they >> won't need any excess capacity. But assuming you know some future >> demand, how do you figure out how much of the future demand you know? >> But sure I can see this as a potential money saver, but unclear by how >> much. The Amazon model for this is a reservation is at minimum a year, >> I am not sure how useful short term reservations would be in >> determining future demand. > > There are other useful things with reservations though. In a private > context the classic one is running number for close of business. Or > software team that's working towards a release might want to preallocate > resources for longer scale runs during a particular week.
Why can't they pre-allocate now? > > Reservation can really be about global policy giving some tenants more > priority in getting resources than others (because you pre-allocate them). > > I also know that with a lot of the HPC teams using OpenStack, this is a > fundamental part of scheduling. Not just the when, but the how long. > Having systems automatically get reaped after a certain amount of time > is something they very much want. Agreed, I think this should either be part of Nova or Heat directly. > > So I think the general idea have merrit. I just think we need to make > sure it integrates well with the rest of OpenStack, which I believe > means strong coupling to the scheduler. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
