[openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

Rabi Mishra ramishra at redhat.com
Tue Jun 26 10:09:40 UTC 2018


On Tue, Jun 26, 2018 at 2:48 PM, Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> Hello Everyone,
>
> In Queens cycle,  community goal to split the Tempest Plugin has been
> completed [1] and i think almost all the projects have separate repo for
> tempest plugin [2]. Which means each tempest plugins are being separated
> from their project release model.  Few projects have started the
> independent release model for their plugins like kuryr-tempest-plugin,
> ironic-tempest-plugin etc [3].  I think neutron-tempest-plugin also
> planning as chatted with amotoki.
>
> There might be some changes in Tempest which might not work with older
> version of Tempest Plugins.


I don't think that's a good premise. Isn't tempest branchless and by
definition should be backward compatible with service releases?

If there are changes in the plugin interface in tempest, I would also
expect those to be backward compatible too. Likewise plugins should be
backward compatible with their respective projects, so any kind of release
model would work.

Else, I think the whole branchless concept is of very little use.

For example, If I am testing any production cloud which has Nova, Neutron,
> Cinder, Keystone , Aodh, Congress etc  i will be using Tempest and Aodh's ,
> Congress's Tempest plugins. With Independent release model of each Tempest
> Plugins, there might be chance that the Aodh's or Congress's Tempest plugin
> versions are not compatible with latest/known Tempest versions. It will
> become hard to find the compatible tag/release of Tempest and Tempest
> Plugins or in some cases i might need to patch up the things.
>
> During QA feedback sessions at Vancouver Summit, there was feedback to
> coordinating the release of all Tempest plugins and Tempest [4] (also
> amotoki talked to me on this as neutron-tempest-plugin is planning their
> first release). Idea is to release/tag all the Tempest plugins and Tempest
> together so that specific release/tag can be identified as compatible
> version of all the Plugins and Tempest for testing the complete stack. That
> way user can get to know what version of Tempest Plugins is compatible with
> what version of Tempest.
>
> For above use case, we need some coordinated release model among Tempest
> and all the Tempest Plugins. There should be single release of all Tempest
> Plugins with well defined tag whenever any Tempest release is happening.
> For Example, Tempest version 19.0.0 is to mark the "support of the Rocky
> release". When releasing the Tempest 19.0, we will release all the Tempest
> plugins also to tag the compatibility of plugins with Tempest for "support
> of the Rocky release".
>
> One way to make this coordinated release (just a initial thought):
> 1. Release Each Tempest Plugins whenever there is any major version
> release of Tempest (like marking the support of OpenStack release in
> Tempest, EOL of OpenStack release in Tempest)
>     1.1 Each plugin or Tempest can do their intermediate release of minor
> version change which are in backward compatible way.
>     1.2 This coordinated Release can be started from latest Tempest
> Version for simple reading.  Like if we start this coordinated release from
> Tempest version 19.0.0 then,
>             each plugins will be released as 19.0.0 and so on.
>
> Giving the above background and use case of this coordinated release,
> A) I would like to ask each plugins owner if you are agree on this
> coordinated release?  If no, please give more feedback or issue we can face
> due to this coordinated release.
>
> If we get the agreement from all Plugins then,
> B) Release team or TC help to find the better model for this use case or
> improvement in  above model.
>
> C) Once we define the release model, find out the team owning that release
> model (there are more than 40 Tempest plugins currently) .
>
> NOTE: Till we decide the best solution for this use case, each plugins can
> do/keep doing their plugin release as per independent release model.
>
> [1] https://governance.openstack.org/tc/goals/queens/split-tempe
> st-plugins.html
> [2] https://docs.openstack.org/tempest/latest/plugin-registry.html
> [3] https://github.com/openstack/kuryr-tempest-plugin/releases
>        https://github.com/openstack/ironic-tempest-plugin/releases
> [4] http://lists.openstack.org/pipermail/openstack-dev/2018-June
> /131011.html
>
>
> -gmann
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180626/2025bf28/attachment.html>


More information about the OpenStack-dev mailing list