build an upgrade strategy
The requirements:
1. Be able to downgrade the database (with some loss of new data) if immediately after an upgrade or during the upgrade process there is failure.
2. Be able to migrate the database for containers that contain new migration scripts
3. Be able to upgrade a running container
4. Keep persistent data intact during an upgrade
5. VMs will not be killed during an upgrade of the Nova service
6. some network delay is acceptable during an upgrade process for VM services connected to neutron
Blueprint information
- Status:
- Complete
- Approver:
- Steven Dake
- Priority:
- Essential
- Drafter:
- Steven Dake
- Direction:
- Approved
- Assignee:
- Steven Dake
- Definition:
- Superseded
- Series goal:
- Accepted for mitaka
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
- Steven Dake
Related branches
Related bugs
Sprints
Whiteboard
Would have marked essential but we don't have to have upgrades implemented, we just have to make sure we CAN implement them later and things will work as expected. This may mean a new environment variable similar to how BOOTSTRAP works. -- sdake
How about two operations:
1) update - updates existing containers with no container database migrations - meant for small patches to OpenStack
2) upgrade - executes a bootstrap-like process which migrates the database then executes the update operation
An update happens as follows:
per node per container:
pull container
if container is new:
delete old container
start new container
-- sdake
Gerrit topic: https:/
Addressed by: https:/
Pin Liberty tarballs to tagged versions.
Addressed by: https:/
Add a new tool to help find the latest versions
Addressed by: https:/
Add a new tool to help find the latest versions
Work Items
Dependency tree
* Blueprints in grey have been implemented.