Bug 999325 - OVIRT35 - [RFE] Framework to publish supported services/protocols and offer a limited set of RPC functions
Summary: OVIRT35 - [RFE] Framework to publish supported services/protocols and offer a...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-node
Version: 3.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Fabian Deutsch
QA Contact: bugs@ovirt.org
URL:
Whiteboard: node
Keywords: FutureFeature
Depends On:
Blocks: ovirt-node-3.1
TreeView+ depends on / blocked
 
Reported: 2013-08-21 07:33 UTC by Fabian Deutsch
Modified: 2016-02-10 19:39 UTC (History)
11 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-10-17 12:26:41 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 18577 None None None Never

Description Fabian Deutsch 2013-08-21 07:33:25 UTC
Description of problem:
As Node becomes more abstract and unspecific and on the other side seeing Node being used in different projects (ovirt, gluster, openstack, foreman, ...) we should add a framework (let's call it FeatureService here) to allow Node and plugins to

a) publish supported features/protocols/services
b) offer triggers e.g. to allow consumers to kick-off the registration with 
   Engine

What has to be defined is

1) What informations plugins (or node itself, which can reuse the same
   mechanism) publish.
   E.g. Do we do something similar to mdns where a service is 
   registered/published?
2) How is the information feed into the framework?
   Programmatically (like plugins are registering themselves with the UI right
   now), or using e.g. an XML file (like for firewalld).
3) How is the information published?
   E.g. RESTless HTTP or py+SSH, or maybe even actively using mDns or upnp?
   Basically we can allow more than on transport method here.
4) Do we allow triggers?

This RFE is a superset of bug 875088, as the above sketched "FeatureService" can publish that it supports Engine, and a trigger/API can be used to kick off the registration.

Some ideas regarding the transport methods and API:
I'd suggest to implement the framework in some python module and try to separate it from the transport protocol.

Comment 1 Sandro Bonazzola 2014-10-17 12:26:41 UTC
oVirt 3.5 has been released and should include the fix for this issue.


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