[Hawkular-dev] bug in MiQ / javaagent integration - needs to be fixed

[John Mazzitelli]

> Is it easy to determine which agent resource maps to the server of interest?
> Perhaps from the feedId on the server resource?

Yup - you use the feed ID. Feed ID of the WildFly Server is the same feed ID of the agent - and there is only one singleton agent per feed ID. So should be easy to find it.

> 
> On 4/27/2017 3:47 PM, John Mazzitelli wrote:
> 
> There is a problem with the new Java agent and MiQ.
> 
> This problem is because the agent is no longer in WildFly's DMR tree of
> resources (because only WildFly subsystems are in the DMR tree).
> 
> Look here:
> https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent-wildfly-feature-pack/src/main/resources/featurepack/content/standalone/configuration/hawkular-javaagent-config.yaml#L596-L603
> So when the agent (java or subsystem agent, doesn't matter) is monitoring
> EAP over the DMR management interface, that's the metadata it uses. You can
> see we inject two non-WildFly attributes (immutable and in-container) under
> the WildFly Server type. But these come from the agent - hence why you see:
> 
>    path: /subsystem=hawkular-wildfly-agent
> 
> But when running this as a java agent, that resource doesn't exist - there is
> no agent subsystem anymore. So the immutable and in-container attributes end
> up not getting defined under the WildFly Server resource.
> 
> The problem is MiQ looks for those attributes under WildFly Servers to
> determine if the agent is in immutable mode and if its running in a
> container.
> 
> In effect, we are trying to inject under a WildFly Server resource completely
> unrelated information (immutable and in-container attributes) - those are
> related to the AGENT, not the WildFly Server itself (i.e. you won't see
> those two attributes if you use the jboss-cli under the root "/" resource).
> 
> We probably should have had MiQ examine the AGENT resource for this (since
> "immutable" and "in container" are attributes on the agent, not the server).
> And we shouldn't define "immutable" and "in container" under the WildFly
> Server resource because that is depending on the fact that the agent is
> running as a subsystem. As a Java Agent, as you see, those attributes will
> never show any values because there is no agent subsystem.
> 
> MiQ can look at the agent attributes because the agent itself exposes
> immutable and in-container (because they ARE actual properties the agent
> has) in inventory. Under the agent resource in inventory you will see these:
> https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent-wildfly-feature-pack/src/main/resources/featurepack/content/standalone/configuration/hawkular-javaagent-config.yaml#L983-L989
> Note that we DO expose immutable and in-container under the Agent JMX
> resource in inventory also - and it has the same resource name as the
> subsystem agent (the name as you will see it in inventory):
> https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent-wildfly-feature-pack/src/main/resources/featurepack/content/standalone/configuration/hawkular-javaagent-config.yaml#L1391-L1399
> Hence why I think the best/easiest thing to do is get MiQ to examine the
> attributes on the resource where they really belong (and we should remove
> them from the WildFly Server type).