[openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload

Alex Glikson GLIKSON at il.ibm.com
Wed Oct 30 06:26:08 UTC 2013


Mike Spreitzer <mspreitz at us.ibm.com> wrote on 30/10/2013 06:11:04 AM:
> Date: 30/10/2013 06:12 AM
> 
> Alex also wrote: 
> ``I wonder whether it is possible to find an approach that takes 
> into account cross-resource placement considerations (VM-to-VM 
> communicating over the application network, or VM-to-volume 
> communicating over storage network), but does not require delivering
> all the intimate details of the entire environment to a single place
> -- which probably can not be either of Nova/Cinder/Neutron/etc.. but
> can we still use the individual schedulers in each of them with 
> partial view of the environment to drive a placement decision which 
> is consistently better than random?'' 
> 
> I think you could create a cross-scheduler protocol that would 
> accomplish joint placement decision making --- but would not want 
> to.  It would involve a lot of communication, and the subject matter
> of that communication would be most of what you need in a 
> centralized placement solver anyway.  You do not need "all the 
> intimate details", just the bits that are essential to making the 
> placement decision. 

Amount of communication depends on the protocol, and what exactly needs to 
be shared.. Maybe there is a range of options here that we can potentially 
explore, between what exists today (Heat talking to each of the 
components, retrieving local information about availability zones, flavors 
and volume types, existing resources, etc, and communicates back with 
scheduler hints), and having a centralized DB that keeps the entire data 
model.
Also, maybe different points on the continuum between 'share few' and 
'share a lot' would be a good match for different kinds of environments 
and different kinds of workload mix (for example, as you pointed out, in 
an environment with flat network and centralized storage, the sharing can 
be rather minimal).

> Alex Glikson asked why not go directly to holistic if there is no 
> value in doing Nova-only.  Yathi replied to that concern, and let me
> add some notes.  I think there *are* scenarios in which doing Nova-
> only joint policy-based scheduling is advantageous.

Great, I am not trying to claim that such scenarios do not exist - I am 
just saying that it is important to spell them out, to better understand 
the trade-off between the benefit and the complexity, and to make sure out 
design is flexible enough to accommodate the high-priority ones, and 
extensible enough to accommodate the rest going forward.

Regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/5d6c2d3b/attachment.html>


More information about the OpenStack-dev mailing list