<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>we definitely need such separation on orchestration layer.<br><br>> Is it possible to have significantly different sets of tasks for controller and primary-controller?<br><br></div>Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and controlled by conditionals inside the manifest. So when we split our tasks into smaller ones, we may want/need to separate them for primary and secondary controllers.<br><br>> I wouldn't differentiate tasks for primary and other controllers. 
"Primary-controller" logic should be controlled by task itself. That 
will allow to have elegant and tiny task framework<br><br></div>Sergii, we still need this separation on the orchestration layer and, as you know, our deployment process is based on it. Currently we already have separate task groups for primary and secondary controller roles. So it will be up to the task developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task.<br><br></div>--<br></div>Regards,<br>Aleksandr Didenko<br><div><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">But without this separation on orchestration layer, we are unable to differentiate between nodes.<div><div>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 </div><div>to node identities (and this mechanism was hardcoded in nailgun for a long time).</div></div><div><br></div><div>Lets say we have task A that is mapped to primary-controller and B that is mapped to "secondary" controller, task B requires task A.</div><div>If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers.</div><div><br></div><div>And how in such case deployment code will know that it should not execute commands in task A for "secondary" controllers and</div><div>in task B on "primary" ?</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,<span><br><br><i>But with introduction of plugins and granular deployment, in my opinion, we need to be able</i><br><div><i>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  executed on 
primary or not.</i></div><br></span>I wouldn't differentiate tasks for primary and other controllers. "Primary-controller" logic should be controlled by task itself. That will allow to have elegant and tiny task framework ...<br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div>
<br><div class="gmail_quote"><div><div>On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hello all,<div><br></div><div>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.</div><div><br></div><div>However, we cannot guarantee that primary controller will be always the same node, because it is not business of nailgun to control elections of primary. Essentially user should not rely on nailgun</div><div>information to find primary, but we need to persist node elected as primary in first deployment</div><div>to resolve orchestration issues (when new node added to cluster we should not mark it as primary).</div><div><br></div><div>So we called primary-controller - "internal" role, which means that it is not exposed to users (or external developers).</div><div>But with introduction of plugins and granular deployment, in my opinion, we need to be able</div><div>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  executed on primary or not.</div><div><br></div><div>Is it possible to have significantly different sets of tasks for controller and primary-controller?</div><div>And same goes for mongo, and i think we had primary for swift also.</div></div>
<br></div></div>__________________________________________________________________________<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></blockquote></div><br></div>
<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></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div>