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

[Brian Stansberry]

> On Mar 13, 2017, at 5:00 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 03/13/2017 01:41 PM, John Mazzitelli wrote:
>>> To me it seems like, when running in WildFly you always want it to be a
>>> subsystem, and when running not in WildFly, you always want it to be an
>>> agent.
>>> 
>>> In other words, you're describing two pieces of software (with some
>>> shared/common code) that do two different things in two different
>>> scenarios, and you're trying to make it all one.
>>> 
>>> If my understanding is correct, I don't think this is really going to
>>> save any work compared to supporting two different things with common
>>> code.  If anything, the combinatory approach going to cause extra work
>>> due to trying to make a square-and-round peg try to fit in a
>>> square-or-round hole.
>> 
>> Well, actually the "have two agents" is going to be more complicated than this "all-in-one agent" - certainly more complicated from a support/maintenance point of view.
>> 
>> I have the all-in-one "java agent" working now (aside from those two issues I mentioned). If I could just get a local ModelController, the same piece of software can monitor:
>> 
>> 1) Local WildFly/EAP servers (standalone and host controller)

Why do you need a ModelControllerClient to look at metrics? I believe metrics should be available over JMX. In another thread you asked about DMR->JMX and mentioned deployments. So if you want to do complex stuff like deployments, or really any writes, using a ModelControllerClient makes sense. But the "WHAT THE AGENT DOES:” section earlier in this thread just talks about metrics.

>> 2) Local JMX servers
>> 3) Remote WildFly/EAP servers (standalone and host controller)
>> 4) Remote JMX Servers
>> 
>> Having this all-in-one javaagent (versus having two separate agents) means the amount of work this would save is quite a lot. For example:
>> 
>> a) We would no longer have to support and maintain the subsystem extension code itself (not to mention all the ancillary code like the feature pack mvn module).
>> 
>> b) We no longer would have to support/maintain/document two different configuration files (one for the <subsystem> in standalone.xml/host.xml and one for the javaagent yaml file)
>> 
>> c) We no longer have to support the agent installer. This agent installer is a piece of additional software that is needed because people complained about having to manually copy the binaries in the add-ons dir and to configure the <subsystem> XML to get the agent installed (along with its related stuff like any required <security-realms> and <socket bindings> that the agent needs).

This security and socket related config that used to be part of the server config is now in a yaml file the the javaagent is configured to access?

>> We ended up writing an installer that can install the add-ons binaries and inject the necessary XML in standalone/host xml so the user doesn't have to. But upgrading such an installment is still a problem - that installer doesn't support upgrading the XML.
>> 
>> Does WildFly today have a subsystem extension installer/upgrader that allows users to install add-ons in their own WildFly servers so a user doesn't have to configure standalone.xml/host.xml with the add-on's required <subsystem> XML?
> 
> Generally speaking, no, not yet, though you can use the CLI to do and 
> script various things.
> 
>> Does it modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on already exists?
> 
> This is automatically done at server start in most if not all cases, not 
> by any tool but by the management model itself.  The XML isn't the 
> model; it's just a serialization of it.  

This depends on what the upgrade is. The server will automatically move a subsystem config to the latest schema version, but if the new code has some new functionality we don’t automatically inject that into the config. Your parser for the old schema version could do that in theory, but generally that’s a bad practice.

> Interaction with the 
> configuration often (usually?) is done via CLI and the console, rather 
> than by manipulating the XML itself.
> 
>> If such a tool exists, that would help a lot. Right now, it is a pain to have to write and maintain the agent's own installer. :) If WildFly has such a tool available already, then this issue with having to maintain/support an installer goes away for me. I did not think such a thing existed, at least not at the time when we wrote this agent installer.
> 
> If you're manipulating XML directly then it's possible that the CLI can 
> do most of what your installer is doing in a more resilient manner, and 
> possibly a simpler manner as well.  Have you looked into it?
> 

The EAP installer itself uses the CLI in this way.

> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat