Alex Glikson <glik...@il.ibm.com> wrote on 10/30/2013 02:26:08 AM:
> Mike Spreitzer <mspre...@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).
I'm not going to claim the direction you're heading is impossible, I am
not good at impossibility proofs. But I do wonder about the why of it.
This came up in the context of the issues around the fact that
orchestration is downstream from joint decision making. Even if that
joint decision making is done in a distributed way, orchestration will
still be downstream from it.
OpenStack-dev mailing list