[openstack-dev] [gate] Re: [fixtures] [Neutron][Stable][Liberty][CLI] Gate broken

Ihar Hrachyshka ihrachys at redhat.com
Wed May 18 08:49:40 UTC 2016


> On 18 May 2016, at 09:55, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> 
> 
>> On 18 May 2016, at 05:31, Darek Smigiel <smigiel.dariusz at 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.

UPD: this patch implements the approach: https://review.openstack.org/317909

I suspect other clients will need to handle similar issues, so I wrote the script in a way that should be easy to adopt for other repos.

> 
> Ihar




More information about the OpenStack-dev mailing list