Bug 999325 - OVIRT35 - [RFE] Framework to publish supported services/protocols and offer a limited set of RPC functions
OVIRT35 - [RFE] Framework to publish supported services/protocols and offer a...
Status: CLOSED CURRENTRELEASE
Product: oVirt
Classification: Community
Component: ovirt-node (Show other bugs)
3.2
Unspecified Unspecified
medium Severity medium
: ---
: 3.5.0
Assigned To: Fabian Deutsch
bugs@ovirt.org
node
: FutureFeature
Depends On:
Blocks: ovirt-node-3.1
  Show dependency treegraph
 
Reported: 2013-08-21 03:33 EDT by Fabian Deutsch
Modified: 2016-02-10 14:39 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-17 08:26:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Node
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


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

  None (edit)
Description Fabian Deutsch 2013-08-21 03:33:25 EDT
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 08:26:41 EDT
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.