<div dir="ltr"><div>Hi,<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>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 class="gmail_signature"><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div>
<br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>__________________________________________________________________________<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>