Neutron should not depend on versioning implementation in novaclient. There is get_contrib_module function in https://review.openstack.org/#/c/152569/9/novaclient/client.py , which should help to renounce the use of direct import of versioning stuff of novaclient, but now, imo, we should use workaround like https://review.openstack.org/#/c/152907/
On Fri, Feb 20, 2015 at 12:38 AM, Terry Wilson <twil...@redhat.com> wrote: > > > ----- Original Message ----- > > On Feb 19, 2015, at 11:52, Terry Wilson <twil...@redhat.com> wrote: > > > > > Unfortunately, the new novaclient release ended up completely breaking > the > > > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > > > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > > > > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > > (no-name-in-module) > > > 2015-02-19 18:37:06.932 | No name 'contrib' in module > > > 'novaclient.v1_1'(no-name-in-module) > > > 2015-02-19 18:37:06.932 | Module > neutron.plugins.cisco.l3.service_vm_lib > > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > > (no-name-in-module) > > > > Hi Terry, > > > > Sorry to hear about this. I looked into this and the problem is pylint > can't > > parse the backward-compatibility we have for the v1_1 deprecation: > > > > > https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm > > > > The actual code should work but pylint static checking will fail to > follow > > it. So far, the options I see to handle it are to either patch > > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific > pylint > > check that's failing (if it's not too broad). > > > > Do you find either of these options acceptable, or have another idea? > > We've currently just disabled the pylint gate tests, and I've posted a > patch for neutron to resolve the issue. Looks like there was a similar > patch already up for review as well, though it only catches one of our uses > of novaclient. There's still a bit of an issue that there is no > version-neutral way to import the 'contrib' stuff like there is for > 'client'. So: > > from novaclient.v1_1.contrib import server_external_events > > has to become > > from novaclient.v2.contrib import server_external_events > > which doesn't work on previous versions of novaclient. It's possible to > hack around it using importutils, but it's pretty ugly. > > Terry > > __________________________________________________________________________ > 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 > -- Best regards, Andrey Kurilin.
__________________________________________________________________________ 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