On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (ikalnit...@mirantis.com) wrote: We can make bidirectional dependencies, just like our deployment tasks do.
Just to make sure we are on the same page… We don’t want to be in a situation where a role needs to know about the its reverse dependencies. Dependencies are always expressed one direction. Right? And, btw, standalone-* roles may have a restriction that at least one node is required. I think it's ok for the plugin is case, since if you don't want to use it - just disable it. On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak <dshul...@mirantis.com> wrote: > 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 > __________________________________________________________________________ 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
