Loading…
This event has ended. Create your own event → Check it out
This event has ended. Create your own
This is the schedule for the Kilo Design Summit, where OpenStack contributors discuss the future of OpenStack development.
Click here for the main OpenStack Summit conference schedule.
View analytic
Wednesday, November 5 • 11:50 - 12:30
Cinder Rolling Upgrades

Sign up or log in to save this to your schedule and see who's attending!

Led by: Duncan Thomas
The proposed change is multi-fold, and the implementation details are not 100% fleshed out yet.

1. All new RPC changes need to leave the old version in place and functional - this might mean inserting blank / default values into new fields, etc. How long the old version(s) need to live needs to be decided - I'd suggest at least a full stable release to enable upgrade from release to release.

2. When adding a new RPC, the code must behave sensibly if that RPC is not received on the far side - the state machine work might help with this since things can be timed out / retried. In some cases admin action might be required, e.g. state reset APIS. This will vary from change to change.

3. On startup, a manager must query the db and see if there are any RPC version requirements in the DB that apply to it. If the requirements cannot be met, then it should exit witha suitable log message. If they can be met, then the requirement should be cached to avoid having to query the DB again. An RPC can be added to cause the cache to be updated without restarting the manager, if desired, however that won't be in the initial version.

4. When sending an RPC, the manager should check the cache for the max version it is allowed to send, and use that. Again, this requires the code to inherently support this kind of fallback, which is a new requirement.

This should mean that an upgrade works as follows:

1. First signal (via a new RPC call or by restarting them) all managers to write their maximum supported RPC versions into the DB. This will be one record per RPC per manager.

2. Update one service. On startup, it works out the maximum RPC version it can currently send by looking at what other can receive and taking the minimum. It also updates the DB with what new versions it can handle, if any.

3. Rolling update more services. They update the DB as appropriate.

4. Either signal via RPC or restart all running services, they should now all see the new version RPCs are supported everywhere.


Wednesday November 5, 2014 11:50 - 12:30
Derain

Attendees (46)