Add new Keystone upgrade logic
We need to change our ks upgrades to follow this guide http://
Working as a coauthor with Duong Ha-Quang:-
Closes-Bug: #1634016 too in the picture iof this BP.
https:/
Commit Message will be updated with Bug ID and BP link
Note: BP is considered as implemented by accepting that we have a small downtime after containers restart.
Blueprint information
- Status:
- Complete
- Approver:
- Michał Jastrzębski
- Priority:
- Essential
- Drafter:
- Michał Jastrzębski
- Direction:
- Needs approval
- Assignee:
- Surya Prakash Singh
- Definition:
- Approved
- Series goal:
- None
- Implementation:
- Implemented
- Milestone target:
- queens-2
- Started by
- Surya Prakash Singh
- Completed by
- Michał Jastrzębski
Related branches
Related bugs
Sprints
Whiteboard
Draft preparation for rolling upgrade :---- https:/
Nowdays there is a big reason why enterprises fail to gain the full
advantage of their OpenStack cloud. Upgrade has never been easy and
in many environments upgrade require extended downtime for both the
control and dataplane, which is an inherently un-cloudy characteristic
of the OpenStack platform. So fixing upgrades would increase adoptation
rate of OpenStack. Being the Identity Service of OpenStack, keystone
play very crusial role in every operation of services. Manual upgrade of
any service is very complex. So with the help of kolla-ansible we will
easily upgrade keystone.
Use Cases
--------------
1-As a Cloud Operator, I want to experience a stable, regularly
upgraded keystone in order to utilize new features, bug fixes
and security enhancements, so that my cloud development
experience is consistently be more enhanced.
2-As a Cloud Operator, I want to provide my users a reliable and available
authentication so that they do not experience any downtime.
4-As a Cloud Operator, I want to be able to roll back the most recent cloud
upgrade I initiate in the event of issues so that I can be confident that
even in the case of errors I will still avoid any downtime.
5-As a Cloud Operator, I want to be able to define characteristics of a
rolling reboot of my data and control plane hosts so that my users are not
impacted by a rolling upgrade.
6-As a Cloud Operator, I want to be able to run pre-upgrade tests to ensure
my cloud is capable of upgrading to a specified version so that I can be
confident in the success of my upgrade.
7-As a Cloud Operator, I want a way to validate whether an upgrade completed
successfully, and get clear indication for any issues and how to resolve
them with specific actions (such as repair, fix and retry, rollback).
8-As a Cloud Operator I want to know beforehand the upgrade plan including
timing, dependencies, and which services would be impacted.
Proposed Change
-------
Need to write some new task on this file : https:/
Need to write playbook which will run on 1st controller node only as keystone services run on controller nodes, play book will mainly contains task as mentioned in step 1 to 7 in http://
This time we need to add 0 downtime specific command logic in bootstrap_
keystone-manage db_sync --expand
keystone-manage db_sync --migrate
keystone-manage db_sync --contract
Implement Keystone zero-downtime upgrade
https:/
Gerrit topic: https:/
Addressed by: https:/
Implement Keystone zero-downtime upgrade
Addressed by: https:/
[WIP] Implement Keystone zero-downtime upgrade
Addressed by: https:/
Ansible strategy for Rolling upgrade
Addressed by: https:/
Apply neutron database migration
Gerrit topic: https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.