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 <ikalnit...@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 <dshul...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
