Currently we have a problem, when new controller added
with lower uid than already deployed controller.
In this case primary-controller will be assigned to new one,
but we already have existing controller which will conflict with
new one.
To overcome this issue primary role will be persisted in
database.
- Added primary attribute for pending_roles and roles tables
by default primary will be False, it will be replaced only
by special Cluster.set_primary_roles procedure
- primary flag wont migrate from roles to pending roles,
because such migration means that node was reseted to bootstrap
- Primary roles used in logic of primary prefix assignment
- For roles that should have primary - has_primary: true
should be added in openstack.yaml
TBD:
- migration from pending roles to roles, currently it is covered
by deployment logic, but maybe there is some cases where we want to do
it explicitly
Reviewed: https:/ /review. openstack. org/136848 /git.openstack. org/cgit/ stackforge/ fuel-web/ commit/ ?id=15106db8838 57ed982823421af 03f6983ac82869
Committed: https:/
Submitter: Jenkins
Branch: master
commit 15106db883857ed 982823421af03f6 983ac82869
Author: Dima Shulyak <email address hidden>
Date: Tue Nov 25 16:22:30 2014 +0200
Persist primary roles in nailgun database
Currently we have a problem, when new controller added
with lower uid than already deployed controller.
In this case primary-controller will be assigned to new one,
but we already have existing controller which will conflict with
new one.
To overcome this issue primary role will be persisted in set_primary_ roles procedure
database.
- Added primary attribute for pending_roles and roles tables
by default primary will be False, it will be replaced only
by special Cluster.
- primary flag wont migrate from roles to pending roles,
because such migration means that node was reseted to bootstrap
- Primary roles used in logic of primary prefix assignment
- For roles that should have primary - has_primary: true
should be added in openstack.yaml
TBD:
- migration from pending roles to roles, currently it is covered
by deployment logic, but maybe there is some cases where we want to do
it explicitly
Closes-Bug: 1390397 b2f8f0f6b9a092e ffb116a33ea
Change-Id: I94b0014e9b4e16