Let me step back a bit...

I really think that for the embedded Wildfly agent, it makes total sense and is preferable to use standalone.xml for the reasons mentioned above. The user is primarily a Wildfly user and he "just" wants to monitor it.

Now, even though I see the benefits in some agent that can support many things (with or without plugins), I am not fully convinced  that it's the right approach. 

- For the docker/kubernetes/cAdvisor/heapster world, it would be more natural to run a Go-lang client with a yaml descriptor, this is kinda the "standard" there. That agent could be in charge of reading metrics for the kubernetes infrastructure + application metrics (through JMX/Jolokia and Prometheus)  (admittedly, the language itself may somehow be hidden if it can run in a small container)
- At the OS/linux level, python seems to be a preferred solution (To be verified).
- ...

(In that case, I would trim down the Wildfly agent for DMR and embedded + domain scenarios.)

To some extend it would simplify some aspects ("no write-back" issue for instance), I understand it adds some duplication + requires a team to become polyglot.

Would we ever need to support 2 same protocoles for 2 different agents, very likely. Even though we seem to have some preferences according to the environment, WF is exposing its DMR interface in "standard" deployments, while it's exposing Jolokia in OpenShift environment.

In nothing else, I think it would help adoption + contributions.

Thomas






On Wed, Sep 7, 2016 at 5:58 AM, Josejulio Martinez Magana <jmartine@redhat.com> wrote:


On Tue, Sep 6, 2016 at 8:27 PM, John Mazzitelli <mazz@redhat.com> wrote:
> What about an utility to export/import that yaml from/to the standard
> configuration file (standalone.xml) ?

That is one idea. However, note there still would be issues that need to be solved:

1) Any change you make to the yaml file would require the user to run the export/import tool again - is that going to be annoying to the user? Are they even going to know they have to run a tool after editing a configuration file? That seems to be annoying to add a second step (1. modify the yaml file 2) run a tool to export the config into standalone.xml). People will most likely forget to do 2.
Yep, I would indeed forget to do it. 

2) This means our export/import tool needs to be smart enough to know how to transform the standalone.xml when the agent configuration is not there yet AND when there is already agent configuration there. We'd need to do something similar to what the agent installer does, which is not trivial.

3) Still doesn't solve the security problems (passwords unencrypted, how to define and reference security realms) - unless we add the security realms in the yaml and have the export/import tool modify the standalone.xml so it modifies the proper security-realms section in standalone xml, too.

4) Still doesn't solve the "no write-back" to the yaml. If you change or add a config setting via the JBoss CLI, it will get persisted to standalone.xml, but it will NOT be persisted to the yaml file. The yaml file essentially becomes stale and you can no longer refer to it and be guaranteed it contains the most up-to-date config. If you run the export/import tool on the stale yaml, you have essentially overwritten the current config in standalone.xml with stale config.
I was thinking, what if instead of having a yaml file, you do something like git. 
e.g. $ hawkular-agent-config path-to-standalone.xml
It would parse standalone.xml and create and open (with vim or some other editor) a yaml file (or some other easy to read/edit format) with the current configuration, you edit, save and close and all the changes go back to the standalone.xml file.
or some other way to actually make it easier to modify agent configuration (like a GUI or command line tool) without having a second configuration file that might be out-of-sync.


_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev


_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev