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}.
>
> 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
