[rhq.next][inventory] Kickoff meeting minutes

Lukas Krejci lkrejci at redhat.com
Wed Dec 3 15:53:26 UTC 2014


Hey,

in the name of doing stuff in public I'm sharing the meeting minutes from the 
first, non-public by my mistake, meeting about the inventory of the yet to be 
named RHQ.next.

We mainly discussed the proposed design document 
https://docs.google.com/document/d/1GNsKZvCebauYFg1ML3FUXZhXF3BPOip9fJiE55x4Hjo/edit
and came to the following conclusions (which will be incorporated into the 
document):

* as of now we are going to keep the nomenclature as it existed in the RHQ but 
we will be renaming stuff where we see fit and find a better alternative.

* we're introducing some new names already though:
- feed: anything that is able to send data to RHQ. The classical RHQ agent is 
an instance of a feed but feeds are a more generic term and we anticipate 
there being many types of them.
- proxy feed: is able to collect data from other feeds and transform, enrich 
or pre-process them before sending them on up to the server (or another proxy 
feed).

* inline with rhq-metrics, we'll be supporting tenants. Most likely tenants 
will be completely separate without any sharing of data possible between them.

* Feeds will have to authenticate to prevent spoofing. How are they going to 
do it is yet to be defined. The authentication will not be used as a means of 
identification, meaning that multiple feeds will be able to share the 
credentials.

* Feeds will have to be able to remember their server-assigned unique ID. This 
does not mean that EVERY feed needs to be able to do that. This just means 
that the feeds that directly communicate with the serve will have to be able 
to do it. It is conceivable that a simple in-app monitoring code will not be 
able to do this, but it is then assumed that this code sends the data to a 
proxy feed that is able to do so.

* we need to work on the definition of and workflows involving a resource type 
or data type. This is a crucial piece of metadata that adds value to the raw 
"numbers" sent up by the feeds.

* The feeds will have different set of capabilities and we will define 
appropriate workflow and feature sets ranging from a "dumb feed" sending only 
monitoring name=value,timestamp triplets to a full-blown agent that is able to 
perform all kinds of functions supported by RHQ including operation 
executions, configuration and monitoring.

* We are unsure about the provisioning aspect of RHQ. While we clearly see the 
utility of it, we're not sure whether it is in the scope of RHQ itself or 
whether it is complex enough to deserve a dedicated solution with which RHQ 
would integrate in some way.

Thanks,

Lukas



More information about the rhq-devel mailing list