---- On Tue, 26 Jun 2018 18:37:42 +0900 Dmitry Tantsur <dtant...@redhat.com>
wrote ----
> On 06/26/2018 11:18 AM, 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.
>
> FWIW this is solved by stable branches for all other projects. If we cannot
> keep
> Tempest compatible with all supported branches, we should back off our
> decision
> to make it branchless. The very nature of being branchless implies being
> compatible with all supported releases.
>
> >
> > 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.
>
> Disclaimer: I'm not the PTL.
>
> Similarly to Luigi, I don't feel well about forcing a plugin release at the
> same
> time as a tempest release, UNLESS tempest folks are going to coordinate
> their
> releases with all how-many-do-we-have plugins. What I'd like to avoid is
> cutting
> a release in the middle of a patch chain or some refactoring just because
> tempest happened to have a release right now.
I understand your point. But we can avoid that case if we only coordinate on
major version bump only. as i mentioned in 1.2 point, Tempest and Tempest
plugins can do their intermediate release anytime which are nothing but
backward compatible release. In this proposed model, we can do a coordinated
release for major version bump only which is happening only on OpenStack
release and EOL of any stable branch.
Or I am all open to have another release model which can be best suited for all
plugins which can address the mentioned use case of coordinated release.
-gmann
>
> >
> > 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-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
