Open Stack

On 03/03/2014 01:35 PM, Joe Gordon wrote:
> On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter <zbitter at 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.

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.

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
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/9cdcb4f4/attachment.pgp>