<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="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 class=""><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 class="h5">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 class="h5"><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>