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... 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.
----- Original Message -----
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:
On Wed, Aug 21, 2013 at 7:30 AM, Alan Pevec apevec@gmail.com wrote:
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 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 phone: +420532294659 | (82) 62659