Bug 901955 - 'keystone-all' script issues
'keystone-all' script issues
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
2.0 (Folsom)
Unspecified Unspecified
unspecified Severity medium
: Upstream M1
: 5.0 (RHEL 7)
Assigned To: RHOS Maint
Ami Jeain
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-20 02:26 EST by Yaniv Kaul
Modified: 2016-04-26 21:18 EDT (History)
9 users (show)

See Also:
Fixed In Version: openstack-keystone-2014.1-4.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, attempting to start the Identity service when it was already running would throw a Python exception. So instead of reporting a useful error message, a raw exception with stack trace was displayed, which may not be very useful to the user. This has been fixed and a more understandable error message is displayed if attempting to start the Identity service when it is already running.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-08 11:23:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1186394 None None None Never

  None (edit)
Description Yaniv Kaul 2013-01-20 02:26:36 EST
Description of problem:
1. It's non standard way of running services. There's no 'start', 'stop' or 'status' for the services. Glance has something similar, at least it's called 'glance-control' which makes more sense than 'keystone-all'.
2. Running it without unknown parameters (such as 'help') does not produce the help, but seems to try and execute it.
3. Running on an already running instance, produces an exception (port already in use):
[root@ykaul-os-keystone ~]# keystone-all -v
Traceback (most recent call last):
  File "/usr/bin/keystone-all", line 104, in <module>
    serve(*servers)
  File "/usr/bin/keystone-all", line 52, in serve
    server.start()
  File "/usr/lib/python2.6/site-packages/keystone/common/wsgi.py", line 70, in start
    socket = eventlet.listen((self.host, self.port), backlog=backlog)
  File "/usr/lib/python2.6/site-packages/eventlet/convenience.py", line 38, in listen
    sock.bind(addr)
  File "<string>", line 1, in bind
socket.error: [Errno 98] Address already in use

Version-Release number of selected component (if applicable):
openstack-keystone-2012.2.1-1.el6ost.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 Alan Pevec 2013-01-22 13:51:33 EST
(In reply to comment #0)
> 1. It's non standard way of running services. There's no 'start', 'stop' or
> 'status' for the services.

On RHEL "openstack-keystone" service is provided:
# service openstack-keystone
Usage: /etc/init.d/openstack-keystone {start|stop|status|restart|condrestart|try-restart|reload|force-reload}

2. and 3. should be fixed upstream.
Comment 3 Adam Young 2013-05-31 15:50:44 EDT
Opened the "Running on an already running instance, produces an exception (port already in use):" as a bug upstream.  The rest of this is a feature request that should be filed upstream.
Comment 9 Udi 2014-07-03 09:23:26 EDT
Running keystone-all when it is already running, exits quietly without printing any output at all. According to the bug it should give a friendly message that the service is already running. Is it acceptable? Should I close the bug?
Comment 10 Arthur Berezin 2014-07-03 10:01:04 EDT
(In reply to Udi from comment #9)
> Running keystone-all when it is already running, exits quietly without
> printing any output at all. According to the bug it should give a friendly
> message that the service is already running. Is it acceptable? Should I
> close the bug?

yes, it's acceptable, we can close it.
Comment 11 Udi 2014-07-03 10:06:02 EDT
Verified in: 
openstack-keystone-2014.1-5.el7ost.noarch
python-keystone-2014.1-5.el7ost.noarch
Comment 13 errata-xmlrpc 2014-07-08 11:23:27 EDT
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.

http://rhn.redhat.com/errata/RHEA-2014-0854.html

Note You need to log in before you can comment on or make changes to this bug.