Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-29 Thread Evgeniy L
Hi, Ok, looks like everybody agree that we should implement similar approach for plugins. But I'm not sure if we should implicitly assume that primary is set if there is only 'controller', in this case we won't be able to run some tasks on controllers only. Thanks, On Thu, Jan 29, 2015 at 1:05

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Dmitriy Shulyak
But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Sergii Golovatiuk
Hi, *But with introduction of plugins and granular deployment, in my opinion, we need to be able* *to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Aleksandr Didenko
Hi, we definitely need such separation on orchestration layer. Is it possible to have significantly different sets of tasks for controller and primary-controller? Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Evgeniy L
Hi, +1 for having primary-controller role in terms of deployment. In our tasks user should be able to run specific task on primary-controller. But I agree that it can be tricky because after the cluster is deployed, we cannot say who is really primary, is there a case when it's important to know

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Dmitriy Shulyak
Also I would like to mention that in plugins user currently can write 'roles': ['controller'], which means that the task will be applied on 'controller' and 'primary-controller' nodes. Plugin developer can get this information from astute.yaml file. But I'm curious if we should change this

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

2015-01-28 Thread Andrew Woodward
On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 for having primary-controller role in terms of deployment. Yes, we need to continue to be able to differentiate the difference between the first node in a set of roles, and all the others. For controllers we have logic