[wildfly-dev] a way to obtain local ModelController within javaagent?

[Jason Greene]

> On Mar 13, 2017, at 2:08 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>> Although I am more generally asking why an agent is needed at all. Why not
>> simply pull from the remote EAP node using a user that is setup for
>> monitoring? That would reduce the software installation and maintenance
>> overhead to just a configuration overhead.
> 
> Can you clarify? Are you asking, “Why not have a single agent running "somewhere" and have it pull from a collection of remote EAP nodes?"

Right thats what I was asking. 

> 
> In fact, this Hawkular Agent does support this kind of deployment (the Agent can be told to monitor N remote servers whether or not those remote servers are running on the same machine or somewhere else on the network).
> 
> One issue with something like that is - most customers do not want to expose their remote management endpoints past the localhost boundary.

It’s very common for our users to do this (for example you can even create users which can only do monitoring operations); so I’ll take it to mean that your understand is that Hawkular’s prefer the call home approach, which is fair enough. I only ask since the approach is being revisited again.

> In that case, this means the agent must be at least installed on the same machine as the EAP node itself even if it isn't running in the same JVM. But now they have to install two things - the agent and the WildFly - albeit on the same machine.


> If that is the case, why not just bundle the agent together with WildFly so you have a single distribution we can call "instrumented WildFly" that a user has to worry about installing? You run your instrumented Wildfly server normally but now you automatically get inventory/metrics uploaded and stored to CloudForms which can then immediately begin to manage it. No need to install and run a separate agent process.

I think thats a totally reasonable approach. The issue in the past was that the lifecycles didn’t match (I can’t remember the details as to why). If things were to remain as a subsystem that has an independent lifecycle, in the future it would be installable via the wildfly provisioning tool (once available). That includes automating adding config blocks as part of installation. If the lifecycles can match, and there is a reliable compatibility contract for the protocol, then we could just merge the capability into the core code.

If you go the agent route though then there is not much we can do to improve the usability as our tooling isn’t going to be able to resolve the possible conflicts that arrive when more than one thing wants to own the bootstrap of the server. 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat