Description of problem: I don't think it's a Horizon bug, feel free to move component. In the services tab, you get information about the services (I'm not sure if it's via keystone service or nova service-list - I believe keystone). However, there's no indication that a service is working or not. Here's a command line example: [root@ykaul-os-horizon ~(keystone_admin)]$ nova service-list ERROR: n/a (HTTP 400) [root@ykaul-os-horizon ~(keystone_admin)]$ keystone service-list +----------------------------------+----------+----------+----------------------------+ | id | name | type | description | +----------------------------------+----------+----------+----------------------------+ | 4a811d58e1264df3b44348c654fc59bc | nova_ec2 | ec2 | EC2 Service | | 60f3fefe09224533a741136debaf119f | glance | image | Openstack Image Service | | 95dc86c43bb745a0832e87f23dc4ff05 | keystone | identity | OpenStack Identity Service | | a53e544c0dc643c8b27250c16cd7f7a9 | nova | compute | Openstack Compute Service | | e873fc26c48f47d8a36166aaff89d5df | cinder | volume | Cinder Service | +----------------------------------+----------+----------+----------------------------+ (My Nova API host was down). I'd be happy to get more than 'enabled' in Horizon, to see that services are responding. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Actually, nova-manage service list does provide this: [root@ykaul-os-nova-api1 ~(keystone_admin)]$ nova-manage service list 2012-12-25 11:06:37 DEBUG nova.utils [req-5fe32888-4add-4529-a350-c6292f76719f None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.6/site-packages/nova/db/sqlalchemy/api.pyc'> __get_backend /usr/lib/python2.6/site-packages/nova/utils.py:502 Binary Host Zone Status State Updated_At nova-scheduler ykaul-os-nova-sched1.qa.lab.tlv.redhat.com nova enabled :-) 2012-12-25 09:06:31 nova-cert ykaul-os-nova-vncproxy.qa.lab.tlv.redhat.com nova enabled XXX 2012-12-23 19:56:52 nova-consoleauth ykaul-os-nova-vncproxy.qa.lab.tlv.redhat.com nova enabled XXX 2012-12-23 19:56:55 nova-compute rhev-a24c-01.mpc.lab.eng.bos.redhat.com nova enabled XXX 2012-12-25 09:15:17 nova-network rhev-a24c-01.mpc.lab.eng.bos.redhat.com nova enabled XXX 2012-12-25 09:15:24 The :-) or XXX show the state, as well as FQDN of resolved IPs of the hosts - which is much more useful than what we have today in Horizon.
I agree that this would be very useful. The nova-manage service list command doesn't quite provide that information, it only shows the state for the nova sub-services (so glance etc are not included). Also nova-manage is a nova administration command that requires root access and is not accessible from the client libraries that Horizon depends on. I don't know if there is a way to do it now, although it's certainly worth investigating further. I'm not sure either which other components could help us enable such a feature: if an individual service is down it can't tell us much. Even if keystone does provide a list of services, it seems beyond its scope as an Identity service to provide state information.
Moving to 3.0 -- this is a feature request that will require a blueprint to be accepted upstream, and is also closer to "Managing OpenStack itself" which may be beyond the scope of Horizon. Not sure in which component such a feature would fit best, though.
Parts of this have been pushed to the upstream repository.
Julie, could you please check out this one?
Verified with : python-django-horizon-2013.2-0.13b3.el6ost.noarch (Havana RHOS 4.0, puddle 2013-10-03.3) From Horizion GUI View: ------------------------- Compute Services Filter Name Host Zone Status State Updated At nova-scheduler cougar15.scl.lab.tlv.redhat.com internal enabled up 0 minutes nova-consoleauth cougar15.scl.lab.tlv.redhat.com internal enabled up 0 minutes nova-conductor cougar15.scl.lab.tlv.redhat.com internal enabled up 0 minutes nova-cert cougar15.scl.lab.tlv.redhat.com internal enabled up 0 minutes nova-network cougar15.scl.lab.tlv.redhat.com internal enabled up 0 minutes nova-compute cougar15.scl.lab.tlv.redhat.com nova enabled up 0 minutes From CLI : ---------- [root@openstack ~(keystone_admin)]# nova service-list +------------------+---------------------------------+----------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +------------------+---------------------------------+----------+---------+-------+----------------------------+-----------------+ | nova-scheduler | cougar15.scl.lab.tlv.redhat.com | internal | enabled | up | 2013-10-13T14:45:02.000000 | None | | nova-consoleauth | cougar15.scl.lab.tlv.redhat.com | internal | enabled | up | 2013-10-13T14:44:59.000000 | None | | nova-conductor | cougar15.scl.lab.tlv.redhat.com | internal | enabled | up | 2013-10-13T14:45:01.000000 | None | | nova-cert | cougar15.scl.lab.tlv.redhat.com | internal | enabled | up | 2013-10-13T14:45:00.000000 | None | | nova-network | cougar15.scl.lab.tlv.redhat.com | internal | enabled | up | 2013-10-13T14:44:59.000000 | None | | nova-compute | cougar15.scl.lab.tlv.redhat.com | nova | enabled | up | 2013-10-13T14:45:02.000000 | None | +------------------+---------------------------------+----------+---------+-------+----------------------------+-----------------+
Adding doc text, will also attach screenshots for clarity.
Created attachment 816156 [details] Compute Services
Created attachment 816158 [details] Network Agents
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-2013-1859.html