[Hawkular-dev] Resourcetype again

[Lukas Krejci]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev