Open Stack

On 21 Oct 2015 at 12:21:57, Igor Kalnitsky (ikalnitsky at 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 <dshulyak at 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 <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  
>  
>  
>  
> __________________________________________________________________________  
> 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/67d7b30e/attachment.html>