[openstack-dev] Climate Incubation Application

Joe Gordon joe.gordon0 at gmail.com
Mon Mar 3 20:30:25 UTC 2014

Overall I think Climate is trying to address some very real use cases,
but its unclear to me where these solutions should live or how to
solve them. Furthermore I understand what a reservation means for nova
but I am not sure what it means in Cinder, Swift etc.

To give a few examples:
* I think nova should natively support booting an instance for a
limited amount of time. I would use this all the time to boot up
devstack instances (boot devstack instance for 5 hours)
* Reserved and Spot Instances. I like Amazon's concept of reserved and
spot instances it would be cool if we could support something similar
* Boot an instances for 4 hours every morning. This sounds like
something that https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron
can handle.
* Give someone 100 CPU hours per time period of quota. Support quotas
by overall usage not current usage. This sounds like something that
each service should support natively.
* Reserved Volume: Not sure how that works.
* Virtual Private Cloud.  It would be great to see OpenStack support a
hardware isolated virtual private cloud, but not sure what the best
way to implement that is.
* Capacity Planning. Sure, but it would be nice to see a more fleshed
out story for it.

It would be nice to see more of these use cases discussed.

On Mon, Mar 3, 2014 at 11:16 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague <sean at dague.net> wrote:
>> 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.
> 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
>> sean at dague.net / sean.dague at samsung.com
>> http://dague.net
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list