<div dir="ltr">Hi,<div><br></div><div>Ok, looks like everybody agree that we should implement similar</div><div>approach for plugins.</div><div>But I'm not sure if we should implicitly assume that primary is set</div><div>if there is only 'controller', in this case we won't be able to run some</div><div>tasks on controllers only.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 1:05 AM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
> Hi,<br>
><br>
> +1 for having primary-controller role in terms of deployment.<br>
<br>
</span>Yes, we need to continue to be able to differentiate the difference<br>
between the first node in a set of roles, and all the others.<br>
<br>
For controllers we have logic around how the services start, and if we<br>
attempt to create resources. This allows the deployment to run more<br>
smoothly.<br>
For mongo the logic is used to setup the primary vs backup data nodes.<br>
For plugins I would expect to continue to see this kind of need and<br>
would need to be able to expose a similar logic when adding roles /<br>
tasks<br>
<br>
I'm however not sure that we need to do this with some kind of role,<br>
this could simply be some parameter that we then use to set the<br>
conditional that we use to apply primary logic already. Alternately,<br>
this could cause the inclusion of 'primary' or 'first node' tasks that<br>
would do these specific work with out the presence of the conditional<br>
to run this testing<br>
<span class=""><br>
> In our tasks user should be able to run specific task on primary-controller.<br>
> But I agree that it can be tricky because after the cluster is deployed, we<br>
> cannot say who is really primary, is there a case when it's important to<br>
> know<br>
> who is really primary after deployment is done?<br>
<br>
</span>for mongo, its important to find out who is currently the primary<br>
prior to deployment starting (which may not have been the primary that<br>
the deployment started with) So it may be special in it's case.<br>
<br>
for controller, its irrelevant as long as it's not set to a newly<br>
added node (a node with a lower <a href="http://node.id" target="_blank">node.id</a> will cause this and create<br>
problems)<br>
<span class=""><br>
> Also I would like to mention that in plugins user currently can write<br>
> 'roles': ['controller'],<br>
> which means that the task will be applied on 'controller' and<br>
> 'primary-controller' nodes.<br>
> Plugin developer can get this information from astute.yaml file. But I'm<br>
> curious if we<br>
> should change this behaviour for plugins (with backward compatibility of<br>
> course)?<br>
><br>
<br>
</span>writing roles: ['controller'] should apply to all controllers as<br>
expected, with the addition of roles: ['primary-controller'] only<br>
applying to the primary controller.<br>
<div class="HOEnZb"><div class="h5">> Thanks,<br>
><br>
><br>
> On Wed, Jan 28, 2015 at 1:07 PM, Aleksandr Didenko <<a href="mailto:adidenko@mirantis.com">adidenko@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> we definitely need such separation on orchestration layer.<br>
>><br>
>> > Is it possible to have significantly different sets of tasks for<br>
>> > controller and primary-controller?<br>
>><br>
>> Right now we already do different things on primary and secondary<br>
>> controllers, but it's all conducted in the same manifest and controlled by<br>
>> conditionals inside the manifest. So when we split our tasks into smaller<br>
>> ones, we may want/need to separate them for primary and secondary<br>
>> controllers.<br>
>><br>
>> > I wouldn't differentiate tasks for primary and other controllers.<br>
>> > "Primary-controller" logic should be controlled by task itself. That will<br>
>> > allow to have elegant and tiny task framework<br>
>><br>
>> Sergii, we still need this separation on the orchestration layer and, as<br>
>> you know, our deployment process is based on it. Currently we already have<br>
>> separate task groups for primary and secondary controller roles. So it will<br>
>> be up to the task developer how to handle some particular task for different<br>
>> roles: developer can write 2 different tasks (one for 'primary-controller'<br>
>> and the other one for 'controller'), or he can write the same task for both<br>
>> groups and handle differences inside the task.<br>
>><br>
>> --<br>
>> Regards,<br>
>> Aleksandr Didenko<br>
>><br>
>><br>
>> On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> But without this separation on orchestration layer, we are unable to<br>
>>> differentiate between nodes.<br>
>>> What i mean is - we need to run subset of tasks on primary first and then<br>
>>> on all others, and we are using role as mapper<br>
>>> to node identities (and this mechanism was hardcoded in nailgun for a<br>
>>> long time).<br>
>>><br>
>>> Lets say we have task A that is mapped to primary-controller and B that<br>
>>> is mapped to "secondary" controller, task B requires task A.<br>
>>> If there is no primary in mapping - we will execute task A on all<br>
>>> controllers and then task B on all controllers.<br>
>>><br>
>>> And how in such case deployment code will know that it should not execute<br>
>>> commands in task A for "secondary" controllers and<br>
>>> in task B on "primary" ?<br>
>>><br>
>>> On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk<br>
>>> <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> But with introduction of plugins and granular deployment, in my opinion,<br>
>>>> we need to be able<br>
>>>> to specify that task should run specifically on primary, or on<br>
>>>> secondaries. Alternative to this approach would be - always run task on all<br>
>>>> controllers, and let task itself to verify that it is  executed on primary<br>
>>>> or not.<br>
>>>><br>
>>>> I wouldn't differentiate tasks for primary and other controllers.<br>
>>>> "Primary-controller" logic should be controlled by task itself. That will<br>
>>>> allow to have elegant and tiny task framework ...<br>
>>>><br>
>>>> --<br>
>>>> Best regards,<br>
>>>> Sergii Golovatiuk,<br>
>>>> Skype #golserge<br>
>>>> IRC #holser<br>
>>>><br>
>>>> On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak<br>
>>>> <<a href="mailto:dshulyak@mirantis.com">dshulyak@mirantis.com</a>> wrote:<br>
>>>>><br>
>>>>> Hello all,<br>
>>>>><br>
>>>>> You may know that for deployment configuration we are serializing<br>
>>>>> additional prefix for controller role (primary), with the goal of deployment<br>
>>>>> order control (primary-controller always should be deployed before<br>
>>>>> secondaries) and some condiions in fuel-library code.<br>
>>>>><br>
>>>>> However, we cannot guarantee that primary controller will be always the<br>
>>>>> same node, because it is not business of nailgun to control elections of<br>
>>>>> primary. Essentially user should not rely on nailgun<br>
>>>>> information to find primary, but we need to persist node elected as<br>
>>>>> primary in first deployment<br>
>>>>> to resolve orchestration issues (when new node added to cluster we<br>
>>>>> should not mark it as primary).<br>
>>>>><br>
>>>>> So we called primary-controller - "internal" role, which means that it<br>
>>>>> is not exposed to users (or external developers).<br>
>>>>> But with introduction of plugins and granular deployment, in my<br>
>>>>> opinion, we need to be able<br>
>>>>> to specify that task should run specifically on primary, or on<br>
>>>>> secondaries. Alternative to this approach would be - always run task on all<br>
>>>>> controllers, and let task itself to verify that it is  executed on primary<br>
>>>>> or not.<br>
>>>>><br>
>>>>> Is it possible to have significantly different sets of tasks for<br>
>>>>> controller and primary-controller?<br>
>>>>> And same goes for mongo, and i think we had primary for swift also.<br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Andrew<br>
Mirantis<br>
Fuel community ambassador<br>
Ceph community<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>