[openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins
Ghanshyam Mann
gmann at ghanshyammann.com
Wed Jun 27 01:43:23 UTC 2018
---- On Tue, 26 Jun 2018 19:32:59 +0900 Mehdi Abaakouk <sileht at sileht.net> wrote ----
> Hi,
>
> I have never understood the branchless tempest thing. Making Tempest
> release is a great news for me.
>
> But about plugins... Tempest already provides a API for plugins. If you
> are going to break this API, why not using stable branches and
> deprecation process like any other software ?
>
> If you do that, plugin will be informed that Tempest will soon do a
> breaking change. Their can update their plugin code and raise the
> minimal tempest version required to work.
>
> Their can do that when they have times, and not because Tempest want to
> release a version soon.
>
> Also the stable branch/deprecation process is well known by the
> whole community.
There is no issue of backward incompatibility from Tempest and on Gate. GATE is always good as it is going with mater version or minimum supported version in plugins as you mentioned. We take care of all these things you mentioned which is our main goal also.
But If we think from Cloud tester perspective where they use older version of tempest for particular OpenStack release but there is no corresponding tag/version from plugins to use them for that OpenStack release.
Idea is here to have a tag from Plugins also like Tempest does currently for each OpenStack release so that user can pickup those tag and test their Complete Cloud.
-gmann
>
> And this will also allow them to release a version when their want.
>
> So I support making release of Tempest and Plugins, but do not support
> a coordinated release.
>
> Regards,
>
> On Tue, Jun 26, 2018 at 06:18:52PM +0900, Ghanshyam Mann 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. 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-tempest-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
>
> --
> Mehdi Abaakouk
> mail: sileht at sileht.net
> irc: sileht
> __________________________________________________________________________
> 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
>
More information about the OpenStack-dev
mailing list