> Yeah I think it's fair to say this is just the first step of probably > several iterations towards fully orchestrated upgrades such as you > describe, atm really it's just a way of pushing out minor updates not > version-to-version upgrades (yet).
Okay, that's cool, I just wanted to make sure I understood the scope of short-term and longer-term plans. Obviously tackling the minor updates part first makes a lot of sense. I think that keeping the bigger picture in mind will help ensure we don't have to redesign things when we set our sights on the larger picture. > You're right to point out how much work is still to be done, both in the > services themselves (to tolerate unexpected restart and DB/RPC version > mismatches), and in defining/automating the workflow which drives the > upgrade. > > There are a few ways to achieve the rolling update you refer to, and work > is going on in both heat and tripleo-common which will help enable this in > future. Cool, I just want to make sure that the work we're doing in Nova and other projects meshes with higher-level plans in this area. Nova is probably due for a blog post detailing the high-level rolling upgrade steps, which would help paint the picture of what tools we're building and expectations we're making. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
