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 A
On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L 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 around how the
> 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
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
w
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 cont
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
time)
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 execu
Hello all,
You may know that for deployment configuration we are serializing
additional prefix for controller role (primary), with the goal of
deployment order control (primary-controller always should be deployed
before secondaries) and some condiions in fuel-library code.
However, we cannot gua
