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

[Brian Stansberry]

Thanks for clarifying about JMX.* 

I’ll answer the question about offline CLI first.

The offline CLI is not a substitute for a full featured installer.  If all you need is some simple conditional logic, e.g. “if subsystem=foo doesn’t exist, add it” or “if subsystem=foo/newfeature=y doesn’t exist, add it” you could just execute the CLI with a script with that kind of logic. And people could certainly edit that kind of script to make simple tweaks. But if you want sophisticated interaction with the user you need something more. (That’s true with an approach based on changing xml too.)

The offline CLI however is something that can be embedded in a more sophisticated installer and can provide that installer client access to the server configuration in a controlled way without any remote interaction involved. This thread is about a request for a hook to get non-remote client access to the server configuration which is why we are pointing to it. It’s a supported solution whose semantics we understand as opposed to something new and unspecified. Using it does not involve needing access to server internals like the ServiceContainer.

I’m unclear what all the javaagent will do. Is it basically just an installer, something that is going to set up the existing subsystem? Or is the existing subsystem basically gone and now the only interaction with the WildFly container is via this ModelControllerClient you are trying to access, and also JMX? So all the interaction with the remote Hawkular server, including security thereof, is hidden inside the agent layer and is unknown to the WildFly server? Or are there other services being installed in or access from the WildFly container?

Extending WildFly by changing standalone.conf/domain.conf to add stuff to JAVA_OPTS isn’t great. It has the same weaknesses as needing to edit standalone.xml, but in a new place. But it is actually easier to externalize some commands to run some code at boot (which AIUI is the only point of your using —javaagent) to a well known location and have our launch scripts read that. Easier than reading and incorporating arbitrary chunks of xml config, which is the longstanding request in this area. And more powerful than reading and executing chunks of CLI script.

* Tangent: TBH I’m not clear why this agent needs to be doing deployments. If it’s a general purpose monitoring agent reusable across a variety of types of processes, deployments are an odd fit.

> On Mar 13, 2017, at 7:42 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>>>> 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.
> 
> Two things:
> 
> 1) Recall that I'm porting an existing agent subsystem that already supported all of this by going through ModelController client. So rather than re-write everything to go over JMX, I'm reusing/refactoring functionality I already have. Going this route let me have a fully functional javaagent in a couple days.
> 
> 2) Plus, yes, as you state, I neglected to say it needs deployment functionality - that requires ModelControllerClient anyway.
> 

Ok, thanks.

>>>> 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?
> 
> Yes. everything is now in yaml - nothing is in standalone.xml if using this javaagent. re: security-realms - I only need truststore definitions (not the full security-realm stuff) so that's all the yaml defines - truststore details. Of course, this means the loss of the vault, so I need a way to somehow obfuscate passwords - but if we are deploying this in OpenShift, I plan on using something like ${x} tokens in the yaml and being able to use OS secrets and somehow pass them to the agent without passwords in plaintext.
> 
>>> 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.
> 
> Yes, I'm sure I could use a CLI script to do most of this. Do people find it acceptable to edit a CLI script if they want to change the default out of box config (as opposed to editing the XML)? How do you, for example, supply a CLI script that lays out a default set of config items for a subsystem but offer a way for customers to customize that out of box config (for example, let them give the installer a truststore with their certs, or let them give you IP addresses and ports they want to use for outbound socket bindings or things like that, if they want to use http skip security-realm definitions but if they want to use https, ask the user for security-realm/truststore details)? Does jboss-cli.sh provide ways to ask questions and set the values of attributes based on the answers?

No, but neither can simple things like xslt. 

> That would be cool. And if it has that functionality, I'm ashamed for not knowing about it :) Honestly, I never looked into whether the CLI can ask for user-input before applying a write-attribute command.

> 
> Also the agent installer also copies binaries to the add-ons directory. It also optionally pulls down the EAP-specific wf-extension.zip (includes the extension module binaries for the add-ons directory and a default xml snippet appropriate for injection into that EAP version) from the hawkular server. It also determines if its installing in EAP 6.4 and if so uses different config than EAP7/Wildfly.
> 
> So writing a set of CLI commands is most but not all it does.

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