[openstack-dev] [qa] Tempest unstable interfaces in plugins

Ken'ichi Ohmichi ken1ohmichi at gmail.com
Sat Jun 11 20:04:09 UTC 2016

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 [0].
>> This work inevitably involves changing the current client manager (unstable)
>> interface.
>> Several tempest plugins in OpenStack already consume that interface (namely
>> the manager.Manager class) [1], so my work is likely to break them.
>> I would ask the people maintaining the plugins to be careful about using
>> unstable interfaces, as they are likely to change, especially since we're
>> 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 review
>> [0], leave a comment there or ping me on IRC (andreaf), I would very much
>> like to make sure the transition is as painless as possible for everyone.
> 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 project.
We did that to pass Ceilometer gate as a workaround[1], 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.

The hacking rule patch is https://review.openstack.org/#/c/328651/
And tempest itself needs to ignore that if merging the rule ;-) [2]

Ken Ohmichi
[1]: https://review.openstack.org/#/c/325727/
[2]: https://review.openstack.org/#/c/328652/

More information about the OpenStack-dev mailing list