> In that model, we would pass a bunch of information about multiple > resources to the solver scheduler, have it perform scheduling *and
> reserve the resources*, then return some kind of resource reservation > tokens back to the caller for each resource. The caller could then > allocate each resource, pass in the reservation token indicating both > that the resources had already been reserved as well as what the specific > resource that had been reserved (the compute-host in the case of an > instance, for example). Here the same problem comes back as with Heat. You can tell Climate to regroup some VMs together. However, the bottom line is that we have no way to pass a bunch of information about multiple resources to the solver scheduler, since the current scheduler API does not allow it. It only accept a command of unique type of resources (flavor) and immediately calculates a provisioning plan for this command. Thus if we want to retains this process and wait for the integrity of all information (by passing several commands, probably with reservation token or a group ID as now) before calculating the provisioning plan, then we have to change the design of the scheduler completely, making it stateful, which, IMO, is much more complicated than adding a new API. > Please be aware that Climate [1] already exists for managing resources > reservations. That doesn't make sense and has been discussed during > last summit that reservations should be managed by Nova, but rather > by another service. No argument here J De : Sylvain Bauza [mailto:sylvain.ba...@gmail.com] Envoyé : mardi 11 février 2014 10:39 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler 2014-02-10 18:45 GMT+01:00 Chris Friesen <chris.frie...@windriver.com>: In that model, we would pass a bunch of information about multiple resources to the solver scheduler, have it perform scheduling *and reserve the resources*, then return some kind of resource reservation tokens back to the caller for each resource. The caller could then allocate each resource, pass in the reservation token indicating both that the resources had already been reserved as well as what the specific resource that had been reserved (the compute-host in the case of an instance, for example). Chris Please be aware that Climate [1] already exists for managing resources reservations. That doesn't make sense and has been discussed during last summit that reservations should be managed by Nova, but rather by another service. -Sylvain [1] : https://launchpad.net/climate
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev