Open Stack

But it will lead to situations, when certain plugins, like
standalone_rabbitmq/standalone_mysql will need to overwrite settings on
*all*
dependent roles, and it might be a problem.. Because, how plugin developer
will be able to know what are those roles?

On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
wrote:

> Hi Dmitry,
>
> > Insert required metadata into roles that relies on another roles, for
> > compute it will be something like:
> >
> >     compute:
> >         requires: controller > 1
>
> Yeah, that's actually what I was thinking about when I wrote:
>
> > Or should we improve it somehow so it would work for one nodes,
> > and will be ignored for others?
>
> So I'm +1 for extending our meta information with such dependencies.
>
> Sincerely,
> Igor
>
> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
> wrote:
> > Hi,
> >
> >> Can we ignore the problem above and remove this limitation? Or should
> >> we improve it somehow so it would work for one nodes, and will be
> >> ignored for others?
> >
> > I think that this validation needs to be accomplished in a different
> way, we
> > don't need 1 controller for the sake of 1 controller,
> > 1 controller is a dependency of compute/cinder/other roles. So from my
> pov
> > there is atleast 2 options:
> >
> > 1. Use tasks dependencies, and prevent deployment in case if some tasks
> > relies on controller.
> > But the implementation might be complicated
> >
> > 2. Insert required metadata into roles that relies on another roles, for
> > compute it will be something like:
> >    compute:
> >      requires: controller > 1
> > We actually have DSL for declaring such things, we just need to specify
> this
> > requirements from other side.
> >
> > But in 2nd case we will still need to use tricks, like one provided by
> Matt,
> > for certain plugins. So maybe we should spend time and do 1st.
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/d5a0a15f/attachment.html>