+++ This bug was initially created as a clone of Bug #1487547 +++ +++ This bug was initially created as a clone of Bug #1259747 +++ Description of problem: Trying to use some tools, I'm getting an error from novaclient. Version-Release number of selected component (if applicable): python-novaclient-2.23.0-2.fc23.noarch How reproducible: always Steps to Reproduce: 1. (setup variables) 2. nova list Actual results: /usr/lib/python2.7/site-packages/keyring/backends/Gnome.py:6: PyGIWarning: GnomeKeyring was imported without specifying a version first. Use gi.require_version('GnomeKeyring', '1.0') before import to ensure that the right version gets loaded. from gi.repository import GnomeKeyring ... Expected results: (no such error) Additional info: --- Additional comment from Lars Kellogg-Stedman on 2015-09-28 22:37:34 JST --- This means that every single OpenStack client invocation starts with this particular error message. $ openstack catalog list > /dev/null /usr/lib/python2.7/site-packages/keyring/backends/Gnome.py:6: PyGIWarning: GnomeKeyring was imported without specifying a version first. Use gi.require_version('GnomeKeyring', '1.0') before import to ensure that the right version gets loaded. from gi.repository import GnomeKeyring $ glance image-list > /dev/null /usr/lib/python2.7/site-packages/keyring/backends/Gnome.py:6: PyGIWarning: GnomeKeyring was imported without specifying a version first. Use gi.require_version('GnomeKeyring', '1.0') before import to ensure that the right version gets loaded. from gi.repository import GnomeKeyring Besides being annoying I know that in the past this sort of unexpected output has confused some of the openstack puppet modules. --- Additional comment from Lars Kellogg-Stedman on 2015-09-28 23:31:16 JST --- You can "fix" (?) this problem by modifying the top of /usr/lib/python2.7/site-packages/keyring/backends/Gnome.py, replacing this: try: from gi import Repository if Repository.get_default().enumerate_versions('GnomeKeyring'): from gi.repository import GnomeKeyring except ImportError: pass With this: try: from gi import Repository, require_version if Repository.get_default().enumerate_versions('GnomeKeyring'): require_version('GnomeKeyring', '1.0') from gi.repository import GnomeKeyring except ImportError: pass --- Additional comment from Justin Holmes on 2015-11-07 11:28:10 JST --- Can confirm that this "fix" works for me on fedora 23 as well. Any chance of getting this packaged into a bug fix? --- Additional comment from Ilkka Tengvall on 2015-11-12 16:48:22 JST --- "me too", works in fedora 23. --- Additional comment from Donny Davis on 2015-11-17 07:30:57 JST --- +1 works here too --- Additional comment from Juan Jimenez on 2015-11-27 03:14:01 JST --- Another +1 --- Additional comment from Christer on 2015-12-04 00:49:36 JST --- Another +1 for fixing this Fedora 23 --- Additional comment from wes hayutin on 2016-01-09 00:28:45 JST --- +1 for a f23 fix --- Additional comment from John Dennis on 2016-01-09 07:20:34 JST --- Why isn't this fixed? It was first reported 4 months ago, the fix is trivial and well known. It's very annoying. Please get a fix pushed out into stable ASAP. Don't forget about rawhide either. Note: same bug has been filed in a few other places: http://permalink.gmane.org/gmane.linux.debian.devel.python.modules/25136 https://bugs.launchpad.net/python-keystoneclient/+bug/1517907 --- Additional comment from Lars Kellogg-Stedman on 2016-01-09 07:43:45 JST --- Please try to keep the contents of bug reports polite. Fedora is a volunteer project, and folks are kind enough to donate their time to help maintain packages. In this case, one reason it hasn't been fixed is that it was initially filed against the wrong component, so the package maintainer wasn't even aware of it until earlier today when moved it to python-keyring. --- Additional comment from John Dennis on 2016-01-09 07:50:34 JST --- My apologies for not seeing it was only assigned today. --- Additional comment from Eduardo on 2016-01-14 01:47:02 JST --- just would like to share that the fix reported by Lars Kellogg-Stedman at 2015-09-28 10:31:16 EDT also worked in my F23 with latest codes (updated at Jan 13 2016) --- Additional comment from Alan Pevec on 2016-01-15 06:43:25 JST --- --- Additional comment from Alan Pevec on 2016-01-15 06:45:00 JST --- --- Additional comment from Ralph Bean on 2016-03-15 02:26:50 JST --- Alan, can you give us some explanation about how this bug is a duplicate of #1195985? We got some feedback today that this bug is causing some performance issues in ansible: http://willthames.github.io/2016/03/12/ansible-slow-startup-on-fedora-23.html --- Additional comment from Jan Vlug on 2016-05-02 18:25:01 JST --- I would also like to see a confirmation that this is a duplicate of bug 1271641, because the "fix" of comment 2 indeed works. Couldn't this issue be fixed separately from bug 1271641? Please package it in a bug fix for Fedora 23. --- Additional comment from Jan Vlug on 2016-06-22 23:30:55 JST --- Please re-open this bug as I still get this error when using hg in Fedora 24. --- Additional comment from Kevin Fenzi on 2016-06-23 00:56:29 JST --- Reopening. Maintainers: Can we take another look here please... --- Additional comment from Charles Butterfield on 2016-09-05 03:30:06 JST --- Many thanks to Lars Kellogg-Stedman, his fix saved my bacon too. Not sure why there is so much resistance to fixing this. Perhaps the maintainers are using some other version and don't see these problem every time they execute a command, but for the rest of us its a royal pain. --- Additional comment from Nick Cross on 2016-09-11 01:54:40 JST --- I am seeing this error message in .xsession-errors on F24 as well --- Additional comment from Fritz Elfert on 2016-10-01 06:02:48 JST --- Still in F24. (tested using python-novaclient-3.3.1-1.fc24.noarch. Shows the same behavior) Fix as suggested in comment #2 still applies nicely. So: what's the holdup? Come on guys, PLEASE fix this already. (Or at least respond with a reason *why* you don't fix this). --- Additional comment from Fritz Elfert on 2016-10-01 06:28 JST --- --- Additional comment from Fritz Elfert on 2016-10-01 06:31 JST --- Hopefully, providing the patch and the diff for the spec file speed up fixing this! --- Additional comment from Kevin Fenzi on 2016-10-03 06:08:07 JST --- So, I looked into this a bit... seems that rawhide and f25 got an update to this package to version 9.0. This bug was actually fixed upstream in version 5.5, but f23 and f24 have 5.0. I'm not the maintainer here, but I'm going to push the fix anyhow. :) If folks could please test and karma the updates that would be great. --- Additional comment from Fedora Update System on 2016-10-03 16:19:43 JST --- python-keyring-5.0-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0e264302f4 --- Additional comment from Fedora Update System on 2016-10-03 16:22:27 JST --- python-keyring-5.0-5.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-68185dfc26 --- Additional comment from Fedora Update System on 2016-10-11 06:49:23 JST --- python-keyring-5.0-5.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from Fedora Update System on 2016-10-11 10:17:51 JST --- python-keyring-5.0-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from on 2017-08-30 14:19:58 JST --- I updated the python-keyring to fc24. [stack@localhost ~]$ yum list python-keyring Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Repo rhel-7-server-extras-rpms forced skip_if_unavailable=True due to: /etc/pki/entitlement/711629419700828312-key.pem Repo rhel-7-server-rh-common-rpms forced skip_if_unavailable=True due to: /etc/pki/entitlement/711629419700828312-key.pem Repo rhel-7-server-rpms forced skip_if_unavailable=True due to: /etc/pki/entitlement/711629419700828312-key.pem Repo rhel-7-server-openstack-8-rpms forced skip_if_unavailable=True due to: /etc/pki/entitlement/711629419700828312-key.pem Repo rhel-7-server-openstack-8-director-rpms forced skip_if_unavailable=True due to: /etc/pki/entitlement/711629419700828312-key.pem Installed Packages python-keyring.noarch 5.0-5.fc24 installed [stack@localhost ~]$ I still met problem. Warning: /Stage[main]/Heat::Deps/Anchor[heat::service::end]: Skipping because of failed dependencies Notice: Finished catalog run in 24.60 seconds + rc=6 + set -e + echo 'puppet apply exited with exit code 6' puppet apply exited with exit code 6 + '[' 6 '!=' 2 -a 6 '!=' 0 ']' + exit 6 [2017-08-30 11:22:19,092] (os-refresh-config) [ERROR] during configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit status 6] [2017-08-30 11:22:19,093] (os-refresh-config) [ERROR] Aborting... Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 815, in install _run_orc(instack_env) File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 699, in _run_orc _run_live_command(args, instack_env, 'os-refresh-config') File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 370, in _run_live_command raise RuntimeError('%s failed. See log for details.' % name) RuntimeError: os-refresh-config failed. See log for details. Command 'instack-install-undercloud' returned non-zero exit status 1 --- Additional comment from Masaki Furuta on 2017-09-01 05:05:15 EDT --- Hi, I found OSP10 or later has python-keyring-5.7.1-1.el7ost, which already include fix at https://bugzilla.redhat.com/show_bug.cgi?id=1259747#c2. But OSP9 and 8 has still have older python-keyring-5.0-3.el7ost, which warns "PyGIWarning: GnomeKeyring was imported without specifying a version first." --- Additional comment from Mike Burns on 2017-09-01 09:03:05 EDT --- Just a note from a content inclusion criteria perspective, this is flagged as medium and OSP 9 is production phase 2. A significant rebase like this is generally frowned upon in prod phase 2 releases. --- Additional comment from Nathan Kinder on 2017-09-06 12:30:18 EDT --- (In reply to Mike Burns from comment #2) > Just a note from a content inclusion criteria perspective, this is flagged > as medium and OSP 9 is production phase 2. A significant rebase like this > is generally frowned upon in prod phase 2 releases. I don't think a rebase is needed. We really would just need to take python-keyring-5.0-5 from Fedora. According to the changelog for the Fedora package, the only code change is the fix for this bug: -------------------------------------------------------------------------------- * Sun Oct 02 2016 Kevin Fenzi <kevin> - 5.0-5 - Fix useless warning message for openstack module use. Fixes bug #1259747 * Thu Feb 04 2016 Fedora Release Engineering <releng> - 5.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild -------------------------------------------------------------------------------- You can see the full changelog here in koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=806225 I think that this makes sense to backport. --- Additional comment from Andreas Karis on 2017-09-09 16:57:42 EDT --- I hit this issue as well with another customer. I'm making all case comments public. I can only stress that we're an OpenSource company and making our case comments private doesn't do anybody any good :-) --- Additional comment from Andreas Karis on 2017-09-09 17:00:41 EDT --- + hit by another customer. So 2 new cases, OSP 7 and 8. It looks as if this is breaking OSP Director minor updates for both of these versions. --- Additional comment from Andreas Karis on 2017-09-09 17:11:17 EDT --- This seems to be pretty easy to work around and doesn't seem to have any dependency issues ... https://apps.fedoraproject.org/packages/python-keyring [stack@undercloud-7 ~]$ rpm -qa | grep python-keyring python-keyring-5.0-1.el7ost.noarch [stack@undercloud-7 ~]$ wget https://kojipkgs.fedoraproject.org//packages/python-keyring/5.0/5.fc24/noarch/python-keyring-5.0-5.fc24.noarch.rpm --2017-09-09 17:10:11-- https://kojipkgs.fedoraproject.org//packages/python-keyring/5.0/5.fc24/noarch/python-keyring-5.0-5.fc24.noarch.rpm Resolving kojipkgs.fedoraproject.org (kojipkgs.fedoraproject.org)... 209.132.181.16, 209.132.181.15 Connecting to kojipkgs.fedoraproject.org (kojipkgs.fedoraproject.org)|209.132.181.16|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 121994 (119K) [application/x-rpm] Saving to: ‘python-keyring-5.0-5.fc24.noarch.rpm’ 100%[============================================================================>] 121,994 629KB/s in 0.2s 2017-09-09 17:10:12 (629 KB/s) - ‘python-keyring-5.0-5.fc24.noarch.rpm’ saved [121994/121994] [stack@undercloud-7 ~]$ sudo yum localinstall python-keyring-5.0-5.fc24.noarch.rpm Loaded plugins: priorities, search-disabled-repos Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast Examining python-keyring-5.0-5.fc24.noarch.rpm: python-keyring-5.0-5.fc24.noarch Marking python-keyring-5.0-5.fc24.noarch.rpm as an update to python-keyring-5.0-1.el7ost.noarch Resolving Dependencies --> Running transaction check ---> Package python-keyring.noarch 0:5.0-1.el7ost will be updated ---> Package python-keyring.noarch 0:5.0-5.fc24 will be an update --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================== Package Arch Version Repository Size ====================================================================================================================== Updating: python-keyring noarch 5.0-5.fc24 /python-keyring-5.0-5.fc24.noarch 443 k Transaction Summary ====================================================================================================================== Upgrade 1 Package Total size: 443 k Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : python-keyring-5.0-5.fc24.noarch 1/2 Cleanup : python-keyring-5.0-1.el7ost.noarch 2/2 Verifying : python-keyring-5.0-5.fc24.noarch 1/2 Verifying : python-keyring-5.0-1.el7ost.noarch 2/2 Updated: python-keyring.noarch 0:5.0-5.fc24 Complete! [stack@undercloud-7 ~]$ --- Additional comment from Andreas Karis on 2017-09-11 13:02:42 EDT --- Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1259747 and https://bugzilla.redhat.com/show_bug.cgi?id=1487547 Modify stackrc and overclourc, change the PYTHONWARNINGS to: ~~~ export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available,ignore:GnomeKeyring was imported" ~~~ --- Additional comment from Andreas Karis on 2017-09-11 13:04:42 EDT --- This is obviously only for the CLI, the services internally will still log this same warning message (e.g. in log of os-collect-config)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:3380