See also:
http://lists.openstack.org/pipermail/openstack-dev/2015-May/063602.html
:-/
-Josh
Jay Pipes wrote:
On 05/08/2015 08:06 AM, Dulko, Michal wrote:
Hi,
I wonder why nova-api or cinder-api aren't present service group API
of each project:
Technically, this is because the API workers do not inherit from
nova.service.Service [1], which is for RPC-based workers. They inherit
from nova.service.WSGIService [2], which is for REST-based workers.
Only the RPC-based workers ever get a service record created in the
services table in the database, and thus only those records appear in
the service list output.
Frankly, the entire services table, DB-based servicegroup API, and the
services API extensions should die in a fire. They don't belong in Nova
or Cinder at all. This kind of thing belongs in ZooKeeper or some other
group monitoring solution, not in the projects themselves.
See also: https://review.openstack.org/#/c/138607/
Best,
-jay
[1] http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n123
[2] http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n308
mdulko:devstack/ (master) $ cinder service-list
+------------------+-------------------------------+------+---------+-------+----------------------------+-----------------+
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+------------------+-------------------------------+------+---------+-------+----------------------------+-----------------+
| cinder-backup | mdulko-VirtualBox | nova | enabled | up |
2015-05-08T11:58:50.000000 | - |
| cinder-scheduler | mdulko-VirtualBox | nova | enabled | up |
2015-05-08T11:58:49.000000 | - |
| cinder-volume | mdulko-VirtualBox@lvmdriver-1 | nova | enabled | up
| 2015-05-08T11:58:50.000000 | - |
| cinder-volume | mdulko-VirtualBox@lvmdriver-2 | nova | enabled | up
| 2015-05-08T11:58:50.000000 | - |
+------------------+-------------------------------+------+---------+-------+----------------------------+-----------------+
Are there any technical limitations to include API services there? Use
case is that when service dies during request processing - it leaves
some garbage in the DB and quotas. This could be cleaned up by another
instance of a service. For that aforementioned instance would need to
know if service that was processing the request is down.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
