<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>We can make bidirectional dependencies, just like our deployment tasks do.
<br>
<br></div></div></span></blockquote><div><br></div><div>Just to make sure we are on the same page…</div><div>We don’t want to be in a situation where a role needs to know about the its reverse dependencies.</div><div>Dependencies are always expressed one direction. Right?</div><div><br></div><blockquote type="cite" class="clean_bq"><span><div><div>And, btw, standalone-* roles may have a restriction that at least one
<br>node is required. I think it's ok for the plugin is case, since if you
<br>don't want to use it - just disable it.
<br>
<br>On Wed, Oct 21, 2015 at 1:15 PM, Dmitriy Shulyak <dshulyak@mirantis.com> wrote:
<br>> But it will lead to situations, when certain plugins, like
<br>> standalone_rabbitmq/standalone_mysql will need to overwrite settings on
<br>> *all*
<br>> dependent roles, and it might be a problem.. Because, how plugin developer
<br>> will be able to know what are those roles?
<br>>
<br>> On Wed, Oct 21, 2015 at 1:01 PM, Igor Kalnitsky <ikalnitsky@mirantis.com>
<br>> wrote:
<br>>>
<br>>> Hi Dmitry,
<br>>>
<br>>> > Insert required metadata into roles that relies on another roles, for
<br>>> > compute it will be something like:
<br>>> >
<br>>> > compute:
<br>>> > requires: controller > 1
<br>>>
<br>>> Yeah, that's actually what I was thinking about when I wrote:
<br>>>
<br>>> > Or should we improve it somehow so it would work for one nodes,
<br>>> > and will be ignored for others?
<br>>>
<br>>> So I'm +1 for extending our meta information with such dependencies.
<br>>>
<br>>> Sincerely,
<br>>> Igor
<br>>>
<br>>> On Wed, Oct 21, 2015 at 12:51 PM, Dmitriy Shulyak <dshulyak@mirantis.com>
<br>>> wrote:
<br>>> > Hi,
<br>>> >
<br>>> >> Can we ignore the problem above and remove this limitation? Or should
<br>>> >> we improve it somehow so it would work for one nodes, and will be
<br>>> >> ignored for others?
<br>>> >
<br>>> > I think that this validation needs to be accomplished in a different
<br>>> > way, we
<br>>> > don't need 1 controller for the sake of 1 controller,
<br>>> > 1 controller is a dependency of compute/cinder/other roles. So from my
<br>>> > pov
<br>>> > there is atleast 2 options:
<br>>> >
<br>>> > 1. Use tasks dependencies, and prevent deployment in case if some tasks
<br>>> > relies on controller.
<br>>> > But the implementation might be complicated
<br>>> >
<br>>> > 2. Insert required metadata into roles that relies on another roles, for
<br>>> > compute it will be something like:
<br>>> > compute:
<br>>> > requires: controller > 1
<br>>> > We actually have DSL for declaring such things, we just need to specify
<br>>> > this
<br>>> > requirements from other side.
<br>>> >
<br>>> > But in 2nd case we will still need to use tricks, like one provided by
<br>>> > Matt,
<br>>> > for certain plugins. So maybe we should spend time and do 1st.
<br>>> >
<br>>> >
<br>>> > __________________________________________________________________________
<br>>> > OpenStack Development Mailing List (not for usage questions)
<br>>> > Unsubscribe:
<br>>> > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br>>> >
<br>>>
<br>>> __________________________________________________________________________
<br>>> OpenStack Development Mailing List (not for usage questions)
<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br>>
<br>>
<br>>
<br>> __________________________________________________________________________
<br>> OpenStack Development Mailing List (not for usage questions)
<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br>>
<br>
<br>__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>