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

[John Mazzitelli]

> >> 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.

> >> 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? 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.