> > This is something to explore to add in Nova, using > a local service or external service (need to explore Climate).
I need to find out more about Climate. Here is Climate Launchpad: https://launchpad.net/climate That's still really young project, but I believe it'll have great future speaking about resource reservation. So if you need some kind of reservation logic, I also believe that should be implemented in Climate (as it's proposed and currently implemented as Reservation-as-a-Service) Thanks On Tue, Feb 11, 2014 at 8:23 PM, Yathiraj Udupi (yudupi) <yud...@cisco.com>wrote: > Hi Dina, > > Thanks for note about Climate logic. This is something that will be > very useful, when we will have to schedule from Nova multiple instances (of > potentially different flavors) as a single request. If the Solver > Scheduler, can make a request to the Climate service to reserve the > resources soon after the placement decision has been made, then the nova > provisioning logic can handle the resource provisioning using the climate > reserved leases. Regarding Solver Scheduler for your reference, just sent > another email about this with some pointers about it. Otherwise this is > the blueprint - > https://blueprints.launchpad.net/nova/+spec/solver-scheduler > I guess this is something to explore more and see how Nova provisioning > logic to work with Climate leases. Or this is something that already works. > I need to find out more about Climate. > > Thanks, > Yathi. > > > On 2/11/14, 7:44 AM, "Dina Belova" <dbel...@mirantis.com> wrote: > > Like a restaurant reservation, it would "claim" the resources for use >> by someone at a later date. That way nobody else can use them. >> That way the scheduler would be responsible for determining where the >> resource should be allocated from, and getting a reservation for that >> resource. It would not have anything to do with actually instantiating the >> instance/volume/etc. > > > Although I'm quite new to topic of Solver Scheduler, it seems to me that > in that case you need to look on Climate project. It aims to provide > resource reservation to OS clouds (and by resource I mean here > instance/compute host/volume/etc.) > > And Climate logic is like: create lease - get resources from common pool > - do smth with them when lease start time will come. > > I'll say one more time - I'm not really common with this discussion, but > it looks like Climate might help here. > > Thanks > Dina > > > On Tue, Feb 11, 2014 at 7:09 PM, Chris Friesen < > chris.frie...@windriver.com> wrote: > >> On 02/11/2014 03:21 AM, Khanh-Toan Tran wrote: >> >>> Second, there is nothing wrong with booting the instances (or >>>> >>> instantiating other >>> >>>> resources) as separate commands as long as we support some kind of >>>> reservation token. >>>> >>> >>> I'm not sure what reservation token would do, is it some kind of >>> informing >>> the scheduler that the resources would not be initiated until later ? >>> >> >> Like a restaurant reservation, it would "claim" the resources for use by >> someone at a later date. That way nobody else can use them. >> >> That way the scheduler would be responsible for determining where the >> resource should be allocated from, and getting a reservation for that >> resource. It would not have anything to do with actually instantiating the >> instance/volume/etc. >> >> >> Let's consider a following example: >>> >>> A user wants to create 2 VMs, a small one with 20 GB RAM, and a big one >>> with 40 GB RAM in a datacenter consisted of 2 hosts: one with 50 GB RAM >>> left, and another with 30 GB RAM left, using Filter Scheduler's default >>> RamWeigher. >>> >>> If we pass the demand as two commands, there is a chance that the small >>> VM >>> arrives first. RamWeigher will put it in the 50 GB RAM host, which will >>> be >>> reduced to 30 GB RAM. Then, when the big VM request arrives, there will >>> be >>> no space left to host it. As a result, the whole demand is failed. >>> >>> Now if we can pass the two VMs in a command, SolverScheduler can put >>> their >>> constraints all together into one big LP as follow (x_uv = 1 if VM u is >>> hosted in host v, 0 if not): >>> >> >> Yes. So what I'm suggesting is that we schedule the two VMs as one call >> to the SolverScheduler. The scheduler then gets reservations for the >> necessary resources and returns them to the caller. This would be sort of >> like the existing Claim object in nova/compute/claims.py but generalized >> somewhat to other resources as well. >> >> The caller could then boot each instance separately (passing the >> appropriate reservation/claim along with the boot request). Because the >> caller has a reservation the core code would know it doesn't need to >> schedule or allocate resources, that's already been done. >> >> The advantage of this is that the scheduling and resource allocation is >> done separately from the instantiation. The instantiation API could remain >> basically as-is except for supporting an optional reservation token. >> >> >> That responses to your first point, too. If we don't mind that some VMs >>> are placed and some are not (e.g. they belong to different apps), then >>> it's OK to pass them to the scheduler without Instance Group. However, if >>> the VMs are together (belong to an app), then we have to put them into an >>> Instance Group. >>> >> >> When I think of an "Instance Group", I think of " >> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension". >> Fundamentally Instance Groups" describes a runtime relationship between >> different instances. >> >> The scheduler doesn't necessarily care about a runtime relationship, it's >> just trying to allocate resources efficiently. >> >> In the above example, there is no need for those two instances to >> necessarily be part of an Instance Group--we just want to schedule them >> both at the same time to give the scheduler a better chance of fitting them >> both. >> >> More generally, the more instances I want to start up the more beneficial >> it can be to pass them all to the scheduler at once in order to give the >> scheduler more information. Those instances could be parts of completely >> independent Instance Groups, or not part of an Instance Group at all...the >> scheduler can still do a better job if it has more information to work >> with. >> >> >> Chris >> >> _______________________________________________ >> 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 > > -- 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