1:42 a.m.
>> 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.