Bug 1494144

+++ 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)