Open Stack

> 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.bauza at 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.friesen at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140211/621ca67f/attachment.html>