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.gord...@gmail.com> wrote: > 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
