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/1GNsKZvCebauYFg1ML3FUXZhXF3BPOip9fJiE5...
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