Hey, Which "this"? :) I would even go further and have that base WF8 type or whatever be defined for the whole Hawkular system and not per tenant. I.e. keeping that definition only once in the system. If that is not possible, we can certainly have that listener install it in each new tenant. Yes. In fact for more complex scenarios we not only need inventory be populated "server side", but the feeds (hawkular-monitor) also need to be able to consume this. Yes. I think so. There is certainly a point in this. Could we actually just shut down a certain api inside inventory (for a certain caller)? Again: two things. We must not allow a malicious feed (i.e. one where an attacker has modified resource type definitions to say "every one can execute") to be uploaded in the server and then prevent any RBAC checks inside the server. The other part which you mention is certainly SSO and "run as" for operations in the agent, which will allow WF to do its own security checking instead of relying that Hawkular has everything correctly set up. Right, if you see the combination of <role(user), WF_Operation> as a runtime property of such a resource. Certainly makes sense, but also makes things more complicated and bloated. That is probably the price for not running inside the target server (like the WF-console).

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 agent can fallback and use its standalone.xml definitions. I have not thought long about the metadata storage in hawkular and the interface the agent should use to get it. We need to figure that out. ----- Original Message -----

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:

Hey, I just had a good discussion with Lukas in the STR office around resource types, metadata, syncing and so on. No conclusion yet, but a much better common understanding. Lukas' idea of metadata packs looks like a promising way forward. We did some drawing on those "whiteboard" glass walls in the office. You can find those two at https://www.dropbox.com/s/oktwsuk1mt4g3fa/IMG_20151020_134356.jpg?dl=0 and https://www.dropbox.com/s/lhlrekprs5xyf2f/IMG_20151020_134406.jpg?dl=0 Heiko