Open Stack

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 <dshulyak at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/d4c7b6f4/attachment.html>