On Sun, Jun 12, 2016 at 2:25 PM Assaf Muller <as...@redhat.com> wrote:
> On Sat, Jun 11, 2016 at 4:04 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> > wrote: > > 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. > > 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 > tempest.{|test|manager}. > 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 [0] 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). [0] https://review.openstack.org/#/c/326683/ > > > > 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 > > __________________________________________________________________________ > 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
