> 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/ === 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
