Thanks, Pavel. Although it would not have helped in this case because the regression was external, we are vulnerable to changes in client libraries breaking library compatibility with stable branches due to lack of testing. I put up a tempest blueprint in July about gating client libraries with runs from stable branches and adding bitrot jobs to make sure the libraries remain compatible: https://blueprints.launchpad.net/tempest/+spec/client-lib-stability. Comments on that approach are appreciated and if it seems like a good idea I would like to get started. -David On 08/25/2013 03:09 PM, Pavel Sedlak wrote:
Generally I fully support
Note: Dolph proposed to pin keyring to <2.0: https://review.openstack.org/#/c/43564/ as he explained also in https://bugs.launchpad.net/devstack/+bug/1193164. This reproducer works (with basic gir1.2 installed, python-gi etc installed).
This 'GnomeKeyring' error appearing in input is a regression between 1.6.1 of python-keyring and 2.0 due to faulty/feature-incomplete merge in https://bitbucket.org/kang/python-keyring-lib/diff/keyring/backends/Gnome.py?diff2=55e8cb1e1848&at=2.0 as there is no 'supported' method, which was doing check without using the guilty 'import GnomeKeyring' directly.
Still it seems that this message is printed by something bellow, like python-gi/gobject inspection etc, python-keyring was doing good job in not triggering it.
So for us, using 1.6.1 is good solution. But as Matthew pointed out, this actually can and happens also on master branch, even there it does not breaks the tests (for whatever reason, and I did not checked many results). Still IMO it's bad to have such amount of unexpected messages in output of our commands. So I would suggest to pin keyring to 1.6.1 also on master/global-reqs as we have there >=1.6.1 and seems there's no reason to require higher.
Just to be safe CCing few people which could know more from keystone/clients PoV so they can warn us if there is any incoming upgrade in reqs from this side.
----- Original Message -----
From: "Pavel Sedlak" <psedlak@redhat.com> To: "Gary Kotton" <gkotton@vmware.com> Cc: "Alan Pevec" <apevec@gmail.com>, "Dolph Mathews" <dolph.mathews@gmail.com>, openstack-stable-maint@lists.openstack.org Sent: Thursday, August 22, 2013 5:01:43 PM Subject: Re: [Openstack-stable-maint] Stable grizzly failures
Hi, sorry for delay I'm looking into it now.
After quick try with master pythonkeystone-client I was unable to reproduce it (but just again older than latest stable/grizzly instance).
I'm going to take that https://bugs.launchpad.net/tempest/+bug/1213912.
From: "Gary Kotton" <gkotton@vmware.com> To: "Alan Pevec" <apevec@gmail.com>, "Dolph Mathews" <dolph.mathews@gmail.com> Cc: openstack-stable-maint@lists.openstack.org, "Pavel Sedlák" <psedlak@redhat.com> Sent: Wednesday, August 21, 2013 7:25:55 PM Subject: RE: [Openstack-stable-maint] Stable grizzly failures
Thanks. Sorry but I have not found the cycles today to look into any of this
-----Original Message----- From: Alan Pevec [mailto:apevec@gmail.com] Sent: Wednesday, August 21, 2013 8:25 PM To: Dolph Mathews Cc: openstack-stable-maint@lists.openstack.org; Pavel Sedlák Subject: Re: [Openstack-stable-maint] Stable grizzly failures
2013/8/21 Dolph Mathews <dolph.mathews@gmail.com>:
Adding Pavel who wrote cli.output_parser according to git log. Tempest is using keystoneclient master, but I don't see any changes in cli output. Pavel, you can check Tempest logs from the last failure[1] but afaict the complete output from subprocess.check_output is not logged, so I'm not sure what happened and confused clii parser. The latest version of keystoneclient looks like it would still pass
On Wed, Aug 21, 2013 at 7:30 AM, Alan Pevec <apevec@gmail.com> wrote: this test. Here's my attempt to reproduce manually: http://pasteraw.com/812w2wwnyhz6nf9b7o0kyzimpepfdo0 As Alan suggested, knowing what tempest is actually seeing from this command is critical to debugging it. BTW this was already filed as https://bugs.launchpad.net/tempest/+bug/1213912
Cheers, Alan
_______________________________________________ Openstack-stable-maint mailing list Openstack-stable-maint@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint -- Pavel Sedlák <psedlak@redhat.com> OpenStack Quality Engineer Red Hat Czech / BRQ irc: psedlak
----- Original Message ----- phone: +420532294659 | (82) 62659