[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