2016-06-10 17:01 GMT-07:00 Assaf Muller <as...@redhat.com>: > On Fri, Jun 10, 2016 at 12:02 PM, Andrea Frittoli > <andrea.fritt...@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] Thanks Ken Ohmichi --- [1]: https://review.openstack.org/#/c/325727/ [2]: https://review.openstack.org/#/c/328652/ __________________________________________________________________________ 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
