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 executed on primary or not.*
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 ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak <dshul...@mirantis.com> wrote: > 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 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 > information to find primary, but we need to persist node elected as > primary in first deployment > to resolve orchestration issues (when new node added to cluster we should > not mark it as primary). > > So we called primary-controller - "internal" role, which means that it is > not exposed to users (or external developers). > 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 executed on primary > or not. > > Is it possible to have significantly different sets of tasks for > controller and primary-controller? > And same goes for mongo, and i think we had primary for swift also. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
