Adapt the upgrades workflow to facilitate stable/mitaka to master (newton)
EDIT:
For now we will use launchpad bugs to track the lifecycle related work for newton (major upgrades, minor updates and mixed version support). The tag is: https:/
Original bp text below. I will also retarget this bp from n3 now.
=======
The current upgrades workflow [1] has been proven to work well for upgrades to upstream liberty. There are currently two known items of work within the wider tripleo community which will impact that workflow - in particular the upgrade of the controller nodes. These are the composable services work, tracked at [2] and the move towards an evolved pacemaker architecture for controller services, tracked at [3]. There may very well be others that can be added here as discovered/
This blueprint is for tracking the work involved with adapting the current upgrades workflow and prove it working for upgrades to master/newton from stable/mitaka. For both major items of work mentioned above, the changes are mostly restricted to the controller nodes.
For the composable services effort, the challenge will be in bringing up the cluster using the 'new' composed services templates - since the implementation there will have completely changed for many services. As just one example, the change that decomposes the base neutron-server and dhcp services removes the resource definitions and constraints from the tripleo-
The migration to an advanced pacemaker architecture is expected to pose a number of difficulties for upgrades. Similarly to the composable services, the challenge will again be in bringing the cluster up to the 'new' architecture. That is, you start with a stable/mitaka overcloud running the legacy pacemaker architecture [6] and upgrade using the latest master/newton tripleo-
Given that a key feature of the new architecture is to retain only core services as managed by pacemaker, its very nature implies some loss in centralised control of _all_ services running on the controller via pacemaker. Furthermore the orthogonal composable controller services effort discussed above means that there can be no assumptions made about exactly which services are deployed and running (and so should be brought back up after an upgrade) on the given controller. We may for example need to construct/store a service manifest before starting the upgrades process to capture the services currently running on the given controller. There is already some work towards this at [8]
[1] "Upgrade documentation" https:/
[2] https:/
[3] https:/
[4] https:/
[5] https:/
[6] http://
[7] http://
[8] https:/
Blueprint information
- Status:
- Complete
- Approver:
- Steven Hardy
- Priority:
- High
- Drafter:
- Marios Andreou
- Direction:
- Approved
- Assignee:
- Marios Andreou
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Marios Andreou
- Completed by
- Emilien Macchi
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Initial rework of pacemaker_
Gerrit topic: https:/
Addressed by: https:/
Adjust UpgradeLevelNov
Bug for upgrading the undercloud (mistral isssue) filed at https:/
Upgrading the undercloud - tracking bugs
-------
Hit a number of issues upgrading the undercloud and they are all already fixed in latest master, so it seems to be packaging/backport related. For tracking I have filed individual bugs and will add them track them here:
-1-> https:/
-2-> https:/
-3-> https:/
-4-> https:/
-5-> https:/
-6-> https:/
^^^ 1-6 should all be fixed by https:/
new bug for undercloud hanging @ https:/
Gerrit topic: https:/
Work Items
Dependency tree

* Blueprints in grey have been implemented.