Open Stack

Robert,

As far as I understood,  Grenade checks and does upgrades.  Instead, the
proposed matrix does not perform any upgrades, it just checks that
different services versions work well together.
Considering that, do you think that the matrix is useful? 

Please let me know if I am not fully understanding Grenade. 

Best Regards,
Pablo

On Sat, 2014-04-26 at 14:29 +1200, Robert Collins wrote:
> Don't confuse current capabilities with goals :-) grenade certainly
> intends to test per service upgrades where that is supported. Eg Nova
> with only the conductor upgraded.
> 
> On 21 Apr 2014 23:27, "Fuente, Pablo A" <pablo.a.fuente at intel.com>
> wrote:
>         Hi,
>         
>         You are right regarding grenade, but there is a subtle
>         difference with
>         the interoperability matrix.
>         Meanwhile grenade does the upgrade and ensures it is working,
>          the
>         matrix checks that different components versions work well (or
>         not)
>         together, hoping that this information helps in the upgrade
>         decisions
>         (for example, upgrades orders).
>         In other words, Grenade moves the entire “cloud” from one
>         version to
>         another (all the components in the same version) and the
>         matrix tests an
>         specific component version against the rest of the cloud in
>         another
>         version.
>         Actually, I am considering to build this matrix without
>         performing any
>         upgrade.
>         
>         Then, do you think this matrix could be helpful?
>         
>         Thank you very much for your answer!
>         Regards,
>         Pablo
>         
>         On Thu, 2014-04-17 at 11:27 -0700, Clint Byrum wrote:
>         > Excerpts from Fuente, Pablo A's message of 2014-04-16
>         14:00:47 -0700:
>         > > 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?
>         > >
>         >
>         > The gate currently has "grenade", which attempts to upgrade
>         a working
>         > stable release to the each commit. If this does not pass, it
>         does not
>         > merge.
>         >
>         > https://wiki.openstack.org/wiki/Grenade
>         >
>         > So this interoperability matrix is actually already
>         maintained, as _every_
>         > commit should be able to upgrade from the previous stable
>         release.
>         >
>         > Failures when attempting to do so are bugs in two things:
>         the thing that
>         > breaks on upgrade, and grenade.
>         >
>         > _______________________________________________
>         > OpenStack-operators mailing list
>         > OpenStack-operators at lists.openstack.org
>         >
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>         
>         _______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators