I disagree about the server being the authoritative source of metadata.
After all it is the feed that actually "sees" and can "touch" the
resource,
not the server.
What the server can (and will) do is to provide for quickly checking if
certain metadata are present in inventory. I preliminarily call it "metadata
packs" which will be a collection of resource, metric and operation types
together with a method to compute their collective hash. The feed then will
check if a pack with a given hash is present in the server and if there is,
then it's good to go.
If the hash does not match it means that some metadata, that the agent expects
(and requires) to correctly describe what it sees, needs to be changed on the
server (i.e. the agent uploads the changes it needs and forms a new pack if it
wants to).
Now for this to make sense, a metadata pack uploaded by one feed (or uploaded
by an operator prior to any feed connecting to the server or even pre-
installed with Hawkular) needs to be "globally visible" so that other feeds
don't have to upload their own version of it with the same hash - i.e. pack
with the same hash should be defined only once in the server.
Why do it this way?
Wildfly agent speaks DMR and can therefore support new functionality/resource
types in the wildfly server without any new code needing to be written. I.e.
the wildfly agent can DEDUCE the metadata directly from what it sees in DMR,
it doesn't need to be told what to see. If it was told, it would also have to
reconcile the differences (i.e. an op is defined on hawk server, but the
underlying wfly doesn't declare it) - i.e. what Heiko is talking about -
fallbacks, compositions of product features, etc.
IMHO, if the agent stays the source of metadata and has the ability to quickly
check that all it needs is already "up with the hawk" then that's a simpler
solution that will be in the end easier on the feeds.
Note that these packs essentially don't need to be user-visible or amendable
"things" - primarily because it would be generally difficult to call them
user-friendly names.
For example, if the agent required (Wfly 10 + product A) it can check for the
presence of the types in 2 ways:
1) 2 calls to inventory checking if "Wfly 10" pack is present and if
"product
A" pack is present) or
2) 1 call to check if "wfly10 + product A" pack is present
If we throw into the mix the "minus 2 components from product A" possibility
as outlined by Heiko, then it becomes quite complex to call it a name or even
"explain" to the user, what this is. But it can still be a metadata pack with
a single hash (the common types would now be members of all 3 packs) and the
agent can still check for its presence with 1 call.
On Tuesday, October 06, 2015 08:56:29 Heiko W.Rupp wrote:
On 6 Oct 2015, at 2:30, John Mazzitelli wrote:
> And a major question still to be addressed is how and when does the
> agent get the type metadata? Right now, it "owns" the metadata in
> standalone.xml. But it would be nice for metadata to be downloaded
> from the hawkular
> server - if there is no metadata available, then the
Yes, the agent should download it from the server
for all those types where we have explicit support
in clients like the UI.
> agent can fallback and use its standalone.xml definitions.
What I did not explicitly mention in my previous mail and the graphic is
that an agent would most probably be able to define their own type
extensions on top of what is there.
So the base type for e.g. a WildFly 9 would come from us (=defined on
the Hawkular server, valid for all feeds of that type) and an then a
user-defined type could be loaded from the agent (and is then again
local to that feed).
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev