[Hawkular-dev] "simpler" agent config ?

[Thomas Heute]

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 at redhat.com> wrote:

>
>
> On Tue, Sep 6, 2016 at 8:27 PM, John Mazzitelli <mazz at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160914/cd589909/attachment.html