> On 18 May 2016, at 09:55, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > >> On 18 May 2016, at 05:31, Darek Smigiel <smigiel.dari...@gmail.com> wrote: >> >> Hello Stable Maint Team, >> It seems that python-neutronclient gate for Liberty is broken[1][2] by >> update for keystoneclient. OpenStack proposal bot already sent update to >> requirements [3], but it needs to be merged. >> If you have enough power, please unblock gate. >> >> Thanks, >> Darek >> >> [1] https://review.openstack.org/#/c/296580/ >> [2] https://review.openstack.org/#/c/296576/ >> [3] https://review.openstack.org/#/c/258336/ > > Right. > > I actually looked at the requirements update yesterday, and the problem is > that it also fails in gate due to fixtures 2.0.0 being used in client gate, > and apparently misbehaving for python3: > > http://logs.openstack.org/36/258336/4/check/gate-python-neutronclient-python34/668ca60/testr_results.html.gz > > This failure occurs only when the failing tests are executed by the same > python thread after any CLITestV20Base based test (like > CLITestV20ExtensionJSONChildResource). The base class mocks out > neutronclient.v2_0.client.Client.get_attr_metadata using > fixtures.MonkeyPatch, and apparently the patch is not cleaned up properly by > fixtures 2.0.0. > > The reason why it fails for Liberty only is that in Mitaka+, we don’t call > this patched method in the course of the failing test runs, and hence don’t > trigger the issue. > > The easiest way to solve that is by switching from fixtures to mock for the > monkey patch. It indeed solves the issue. If we go this route, ideally, we > would probably do the same for all branches starting from master, even if the > issue is not currently triggered there. > > I would like to hear from client folks whether it’s a reasonable approach > here to just switch to mock and backport, or we want to stick to fixtures and > bring the issue with fixtures authors. Note that in neutron, we were already > hit by the release monkey patch breakage before, and switched to using mock > in base test class: > > https://review.openstack.org/#/c/302997/
UPD: I pushed some patches for master that should be merged and backported back to stable/liberty to fix python3 gate there: https://review.openstack.org/#/q/topic:bug/1583029 [assuming we are fine with switching to mock there, for which I don’t see any reason not to]. > > === > > Now, the question is why the new fixtures release broke us. In Liberty, we > already have constraints in place, right? Not really. For clients, we have > not applied them (even in master). I made initial attempt to do it, by adding > -c… to install_command in the repo, but was hit by an issue: > > Obtaining file:///home/vagrant/git/python-neutronclient > Could not satisfy constraints for 'python-neutronclient': installation from > path or url cannot be constrained to a version > > This happens because we have usedevelop = True in tox.ini, so it tries to > install the client from the repo path. But since upper-constraints.txt also > contains the client version pin, pip detects version conflict and fails. This > does not happen for neutron where we also use usedevelop = True because > neutron package version is not tracked in openstack/requirements and is not > pinned in upper-constraints.txt. > > In devstack, before installing a library from git, we modify the provided > constraints file, by replacing the library version pin with file:// > definition: > > http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n160 > > To make it work for tox based jobs, we would need to apply the same strategy > as part of install_command for all clients. Meaning, we would need a hack > similar to tox_install.sh found in neutron-*aas repos. We would also need to > install openstack/requirements as part of the process to get access to > edit-constraint tool. > > Ihar __________________________________________________________________________ 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
