Open Stack

On 10/30/2012 12:12 PM, Dan Smith wrote:
> Hi all,
>
> I have gone through the etherpad[*] for the "Road to live upgrade"
> summit session and pulled out what I believe are the necessary action
> items. Below are the artifacts/blueprints (with names) I plan to create
> as a result, but I wanted to float them here for comments before I do.
>
> - Add a wiki page to document best practices for writing new database
>    migrations. Some of these are documented in the "Suggestions" portion
>    of the etherpad, but this will require some work by people that
>    really understand the pitfalls and perils of that work.

While looking for the right place to add this, I came across this 
existing wiki page (very sparse) - 
http://wiki.openstack.org/ReviewChecklist. Seems like the right place we 
should start? I think there were a lot of concrete comments on what a 
good migration looks like as part of that which we should write down.

> - Add a nova blueprint for inserting sample data into the database
>    prior to migration testing (migration-testing-with-data). The group
>    identified the need to do migration tests with more than an empty
>    database to catch consistency issues.
>
> - Add a QA blueprint for multinode testing (multinode-testing).
>
> - Add a QA blueprint for doing nightly runs of Grenade (nightly-upgrade-
>    testing).
>
> - Add a nova blueprint for versioning the RPC wireline format (version-
>    rpc-messages). The group confirmed the findings of the previous
>    session on trusted RPC with respect to the need for versioned RPC
>    wireline messages so that future improvements can be made without
>    requiring cluster-atomic upgrades.
>
> - Add a nova blueprint for controlling the version used for outbound
>    RPC messages (rpc-version-control). Right now, a version N+1 node
>    can receive and handle version N messages, but can only send version
>    N+1 messages. Allowing an admin to lock down the RPC version until
>    all nodes have been upgraded allows for graceful cluster-wide
>    upgrades.

I'm not sure we fully got to the solution here, but we at least know 
that the fact that RPC versioning is only a receiver function isn't good 
enough, as sometimes nova-compute needs to cross talk.

Whether this is an admin thing, or a negotiated thing is I think 
something that can be sorted out once someone finally starts tackling 
the problem.

> - Add a QA (?) blueprint for mixed-version RPC testing (mixed-
>    rpc-version-testing). This was a proposed attempt to specifically
>    test a commit against the previous to ensure that the RPC layers can
>    communicate (i.e. pass all the regular RPC tests). I figure this will
>    be a scary script to splice things together, and that it could/would
>    be run as part of gate or nightly testing.
>
> - Add a nova blueprint for versioning notifications (versioned-
>    notifications). The group identified the need to version notification
>    messages for the same reason as RPC messages.
>
> Comments?
>
> *: https://etherpad.openstack.org/grizzly-live-upgrade

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com