On Mon, Mar 3, 2014 at 9:22 AM, Dina Belova <dbel...@mirantis.com> wrote: > Joe, as said, Amazon reservation is not like implemented in Climate - and > really we had different original use cases to have the same result. Amazon > instances reservations do not guarantee that instance will be provided to > user, as in Climate we started implemented reservations possibilities with > this guarantee (due to original use cases). That's why we're mostly speaking > about time-based resource management now, not billing purposes. >
"Reliable Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them." https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ That sounds like a guarantee to me. How does climate enforce a guarantee while freeing the physical resource for something else to use? Otherwise you are consuming a resource without charging anyone (assuming you don't charge anything for a reservation for a lease that hasn't started. > Lease creation request now contains the following steps: create lease -> > start lease -> end lease > Also there are user notifications, but they are connected with lease > start/end events, so that's not some separated stuff now. > > Although, if we'll implement one more second step like 'allocate resources' > - that will allow us to have reservations with no guarantees, and that will > make Climate possibilities containing Amazon use case. > > Thanks > > > On Mon, Mar 3, 2014 at 9:04 PM, Joe Gordon <joe.gord...@gmail.com> wrote: >> >> On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle <a...@openstack.org> wrote: >> > >> > >> > On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon <joe.gord...@gmail.com> >> > wrote: >> >> >> >> On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza <sylvain.ba...@bull.net> >> >> wrote: >> >> > Hi Joe, >> >> > >> >> > Thanks for your reply, I'll try to further explain. >> >> > >> >> > >> >> > Le 03/03/2014 05:33, Joe Gordon a écrit : >> >> > >> >> >> On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova <dbel...@mirantis.com> >> >> >> wrote: >> >> >>> >> >> >>> Hello, folks! >> >> >>> >> >> >>> I'd like to request Climate project review for incubation. Here is >> >> >>> official >> >> >>> incubation application: >> >> >>> >> >> >>> https://wiki.openstack.org/wiki/Climate/Incubation >> >> >> >> >> >> I'm unclear on what Climate is trying to solve. I read the 'Detailed >> >> >> Description' from the link above, and it states Climate is trying to >> >> >> solve two uses cases (and the more generalized cases of those). >> >> >> >> >> >> 1) Compute host reservation (when user with admin privileges can >> >> >> reserve hardware resources that are dedicated to the sole use of a >> >> >> tenant) >> >> >> 2) Virtual machine (instance) reservation (when user may ask >> >> >> reservation service to provide him working VM not necessary now, but >> >> >> also in the future) >> >> > >> >> > Climate is born from the idea of dedicating compute resources to a >> >> > single >> >> > tenant or user for a certain amount of time, which was not yet >> >> > implemented >> >> > in Nova: how as an user, can I ask Nova for one compute host with >> >> > certain >> >> > specs to be exclusively allocated to my needs, starting in 2 days and >> >> > being >> >> > freed in 5 days ? >> >> > >> >> > Albeit the exclusive resource lock can be managed on the Nova side, >> >> > there is >> >> > currently no possibilities to ensure resource planner. >> >> > >> >> > Of course, and that's why we think Climate can also stand by its own >> >> > Program, resource reservation can be seen on a more general way : >> >> > what >> >> > about >> >> > reserving an Heat stack with its volume and network nested resources >> >> > ? >> >> > >> >> > >> >> >> You want to support being able to reserve an instance in the future. >> >> >> As a cloud operator how do I take advantage of that information? As >> >> >> a >> >> >> cloud consumer, what is the benefit? Today OpenStack supports both >> >> >> uses cases, except it can't request an Instance for the future. >> >> > >> >> > >> >> > Again, that's not only reserving an instance, but rather a complex >> >> > mix >> >> > of >> >> > resources. At the moment, we do provide way to reserve virtual >> >> > instances >> >> > by >> >> > shelving/unshelving them at the lease start, but we also give >> >> > possibility to >> >> > provide dedicated compute hosts. Considering it, the logic of >> >> > resource >> >> > allocation and scheduling (take the word as resource planner, in >> >> > order >> >> > not >> >> > to confuse with Nova's scheduler concerns) and capacity planning is >> >> > too >> >> > big >> >> > to fail under the Compute's umbrella, as it has been agreed within >> >> > the >> >> > Summit talks and periodical threads. >> >> >> >> Capacity planning not falling under Compute's umbrella is news to me, >> >> are you referring to Gantt and scheduling in general? Perhaps I don't >> >> fully understand the full extent of what 'capacity planning' actually >> >> is. >> >> >> >> > >> >> > From the user standpoint, there are multiple ways to integrate with >> >> > Climate >> >> > in order to get Capacity Planning capabilities. As you perhaps >> >> > noticed, >> >> > the >> >> > workflow for reserving resources is different from one plugin to >> >> > another. >> >> > Either we say the user has to explicitly request for dedicated >> >> > resources >> >> > (using Climate CLI, see dedicate compute hosts allocation), or we >> >> > implicitly >> >> > integrate resource allocation from the Nova API (see virtual instance >> >> > API >> >> > hook). >> >> >> >> I don't see how Climate reserves resources is relevant to the user. >> >> >> >> > >> >> > We truly accept our current implementation as a first prototype, >> >> > where >> >> > scheduling decisions can be improved (possibly thanks to some tight >> >> > integration with a future external Scheduler aaS, hello Gantt), where >> >> > also >> >> > resource isolation and preemption must also be integrated with >> >> > subprojects >> >> > (we're currently seeing how to provision Cinder volumes and Neutron >> >> > routers >> >> > and nets), but anyway we still think there is a (IMHO big) room for >> >> > resource >> >> > and capacity management on its own project. >> >> > >> >> > Hoping it's clearer now, >> >> >> >> Unfortunately that doesn't clarify things for me. >> >> >> >> From the user's point of view what is the benefit from making a >> >> reservation in the future? Versus what Nova supports today, asking for >> >> an instance in the present. >> >> >> >> Same thing from the operator's perspective, what is the benefit of >> >> taking reservations for the future? >> >> >> >> This whole model is unclear to me because as far as I can tell no >> >> other clouds out there support this model, so I have nothing to >> >> compare it to. >> >> >> > >> > Hi Joe, >> > I think it's meant to save consumers money by pricing instances based on >> > today's prices. >> > >> > https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ >> >> >> The reserved concept in Amazon, is very different then the one >> proposed here. The amazon concept doesn't support saying I will need >> an instance in 3 days, this is trying to support that use case. >> Furthermore I am not sure how the climate proposal would allow a >> cloud provider to offer a cheaper offering. >> >> > >> > Anne >> > >> >> >> >> > -Sylvain >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> > >> > >> > >> > _______________________________________________ >> > 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 > > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > > _______________________________________________ > 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
