[openstack-dev] Rolling upgrades in icehouse

Tim Bell Tim.Bell at cern.ch
Mon Mar 24 19:31:54 UTC 2014


How does this interact with cells ? Can the cell API instances be upgraded independently of the cells themselves ?

My ideal use case would be

- It would be possible to upgrade one of the cells (such as a QA environment) before the cell API nodes
- Cells can be upgraded one-by-one as needed by stability/functionality
- API cells can be upgraded during this process ... i.e. mid way before the most critical cells are migrated

Is this approach envisaged ?

Tim


> -----Original Message-----
> From: Dan Smith [mailto:dms at danplanet.com]
> Sent: 24 March 2014 20:14
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Rolling upgrades in icehouse
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Where can I obtain more information about this feature?
> 
> - From the blog post that I've yet to write :D
> 
> > Does above imply that database is upgraded along with control service
> > update as well?
> 
> Yes, but only for the services that interact directly with the database. The services that do *not* need to be upgraded atomically with
> the schema are: nova-compute and nova-network.
> 
> > One more question - is there an initiative to make icehouse database
> > schema work with havana based control services ?
> 
> It depends on what you mean by "control services". For icehouse, the incremental step that we're making is that all the controller
> services must be upgraded atomically with the database schema. That means api, scheduler, conductor, etc. A havana compute node
> is sufficiently isolated from the data schema that it will continue to work with an icehouse conductor, allowing you to upgrade
> compute nodes independently after the controller services are updated.
> 
> This was just our first step at providing some capability for this. We hope to continue to increase the capabilities (and decrease the
> amount that must be done atomically) going forward.
> 
> Hope that helps!
> 
> - --Dan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJTMIP6AAoJEBeZxaMESjNVSrYH/ixFKup4jRu5THMq5+X9td/S
> 0lJfTTTBUki2ikmi/mvSPN4Dtfes+SdfkK71EF09B2Za+rq29A4QTLf0RQHSqeFR
> NpOzTf/baqxUcWroDe/HNLakVd2KnBwh1n3XhEU7Wy+7wzYLl9uLQ/ZguyjazfZv
> vt7aAs/VtLpYARx4MdK3vopjSuSdVlfHP+0vhPTzoxyDSRzudDh7FRddGLEjjVlX
> WUHWNePNmdgRzKAFarvyw3qipEuR4kaPqZh3bWr4fIxB6ZQzOA+fa5hkIg3vnD3D
> 0sLznbZkKevLxhSEX+ml3Gfk2Ax3UVIdAai5JxH+LAka2tiVCrwHQMeKyu7lxFw=
> =JYp4
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list