---- On Tue, 26 Jun 2018 19:12:33 +0900 Dmitry Tantsur <dtant...@redhat.com>
wrote ----
> On 06/26/2018 11:57 AM, Ghanshyam Mann wrote:
> >
> >
> >
> > ---- 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.
>
> Even bigger concern: what if the plugin is actually not compatible yet? Say,
> you're releasing tempest 19.0. As the same point you're cutting
> ironic-tempest-plugin 19.0. Who guarantees that they're compatible? If we
> haven't had any patches for it in a month, it may well happen that it does
> not work.
On gate, their are being usually tested with latest tempest until tempest is
capped. There is no single place of testing all plugins which is not feasible
too but each plugins running in gate will break if Tempest introduced any
backward incompatible change. My proposal or user request about this
coordinated release is testing cloud with older version of Tempest and plugins.
For gate there is no issue but for Cloud tester it create the issue. I tried to
explain it in more clear way here -
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131850.html
-gmann
>
> >
> > 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.
>
> My suggestion: tempest has to be compatible with all supported releases (of
> both
> services and plugins) OR be branched.
>
> >
> > -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
> >
>
>
> __________________________________________________________________________
> 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
