[openstack-dev] [qa] Tempest unstable interfaces in plugins
andrea.frittoli at gmail.com
Mon Jun 13 09:58:34 UTC 2016
On Sun, Jun 12, 2016 at 2:25 PM Assaf Muller <assaf at redhat.com> wrote:
> On Sat, Jun 11, 2016 at 4:04 PM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
> > 2016-06-10 17:01 GMT-07:00 Assaf Muller <assaf at redhat.com>:
> >> On Fri, Jun 10, 2016 at 12:02 PM, Andrea Frittoli
> >> <andrea.frittoli at gmail.com> wrote:
> >>> Dear all,
> >>> I'm working on making the client manager in Tempest a stable
> interface, so
> >>> that in future it may be used safely by plugins to easily gain access
> >>> service clients .
> >>> This work inevitably involves changing the current client manager
> >>> interface.
> >>> Several tempest plugins in OpenStack already consume that interface
> >>> the manager.Manager class) , so my work is likely to break them.
> >>> I would ask the people maintaining the plugins to be careful about
> >>> unstable interfaces, as they are likely to change, especially since
> >>> working on converting them to stable.
> >>> If you maintain a plugin (in OpenStack or outside of OpenStack) that is
> >>> likely to be affected by my work, please keep an eye on my gerrit
> >>> , leave a comment there or ping me on IRC (andreaf), I would very
> >>> like to make sure the transition is as painless as possible for
> >> FWIW this doesn't seem to break Neutron:
> >> https://review.openstack.org/#/c/328398/.
> >> I would appreciate it if changes are made in a backwards compatible
> >> manner (Similar to this:
> >> https://review.openstack.org/#/c/322492/13/tempest/common/waiters.py)
> >> so that projects with Tempest plugins may adapt and not break voting
> >> jobs. The reason projects are using interfaces outside of tempest.lib
> >> is that that's all there is, and the alternative of copy/pasting in to
> >> the repo isn't amazing.
> > Yeah, copy/pasting of tempest code which is outside of tempest.lib is
> > not amazing.
> > However, that is a possible option to continue gate testing on each
> > We did that to pass Ceilometer gate as a workaround, then
> > we(QA-team) knew what lib code is necessary and are concentrating on
> > making the code as tempest.lib.
> > After finishing, we can remove the copy/pasting code from Ceilometer
> > by using new tempest.lib code.
> > During this work, I feel it is nice to add a new hacking rule to block
> > importing the local tempest code from other projects.
> > From viewpoints of outside of QA team, it would be difficult to know
> > the stability of tempest code I guess.
> > Then by adding a rule, most projects know that and it is nice to
> > ignore it by understanding the stability.
> I added a comment on the patch, but when I looked in to this a couple
> of months ago, Neutron, Ironic and Heat all imported
Within OpenStack only the list of plugins importing client manager is
rather long, which is why I sent this message to begin with :)
I made a new patch-set in  now which keeps manager.Manager around while
the new stable manager is being prepared. This ensures backward
compatibility and emits a warning. Once the client manager moves to
tempest.lib namespace I'll send another email asking folks to update their
plugins, and eventually remove the version in Tempest (after a grace time).
> > The hacking rule patch is https://review.openstack.org/#/c/328651/
> > And tempest itself needs to ignore that if merging the rule ;-) 
> > Thanks
> > Ken Ohmichi
> > ---
> > : https://review.openstack.org/#/c/325727/
> > : https://review.openstack.org/#/c/328652/
> > 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev