[Openstack-operators] [Upgrades] Interoperability Matrix

Fuente, Pablo A pablo.a.fuente at intel.com
Thu Apr 17 14:48:56 UTC 2014


Running this against a particular commit or a version tag
(Grizzly/Havanna/Icehouse) will be the same, since a particular version
tag it is also a commit. So, it could be good if the generated matrix
for a particular version tag is stored, for easy access and checking.

Regarding the implementation, the idea is to use devstack to deploy all
the OpenStack projects in a specific version, except the project that
you want to check (e.g. all projects at Havanna, Nova at Icehouse).
Then, over that deploy, to run a particular subset of Tempest tests, and
use the output to build the matrix.         

Pablo.

On Wed, 2014-04-16 at 23:16 -0300, gustavo panizzo wrote:
> On 04/16/2014 06:00 PM, Fuente, Pablo A wrote:
> > Hi guys,
> > 
> > I would like to open a discussion related to OpenStack upgrades ( I mean
> > moving from one version to another, for example Havana to Icehouse).
> > 
> > As you probably know, this is a big issue, since there is no silver
> > bullet to do it. For that reason, I am thinking  in an option to provide
> > more input prior to do an upgrade.
> > 
> > The idea is to generate an interoperability matrix, where devops can see
> > if an specific commit works with all the available OpenStack versions,
> > distinguishing among the different components. For example, you could
> > see if  the Nova X commit is or not backward compatible with the
> > Grizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...
> > 
> > Do you think this matrix would be useful in the upgrade tasks? 
> 
> i think if you do it for each commit will be more useful for clouds that
> follow trunk that ones that upgrade each release.
> 
> if i'm going to upgrade from havana to icehouse i won't look at each
> commit, just the final result, like
> 'i can/can't use Havana's nova with Icehouse's keystone' that data could
> be extracted from that big matrix (lot of commits btw each release for
> each component)
> 
> 
> it sounds extremely useful for people thinking on moving it's cloud to a
> CD model :)
> 
> 
> how will you generate that matrix? adding tags to commits or running
> fine-grained tempest-like tests?
> 
> 



More information about the OpenStack-operators mailing list