Honestly, once I am using a configuration management system (like Puppet) it doesn't
really matter that it is another file, especially once someone has released a puppet
module to do all the lifting. I recently deployed (on a side project) collectd, graphite,
grafana, and the ELK stack without touching any of their config files directly and
specifying only a minimal set of values that differed from convention.
If the goal is to work well with tooling used by sys admins, like Puppet/Chef/etc, then we
really should develop and release our own modules for whatever we want to support. If
configuration is file based, this will take the developer maybe a couple hours for each
supported toolset.
If the configuration is inside EAP, then it is still possible, just difficult. Don't
expect the community to do it on their own. It requires integrating non-java languages
with the management interfaces. You can see an example of what is required for doing this
with Puppet in the module I linked before (and it can be used for configuring hawkular if
its config is in container). Similar work would need to be done for whatever other config
management chosen. Expect to spend several weeks for each variant going this way.
----- Original Message -----
> Am 13.02.2015 um 20:19 schrieb Chris Pitman
<cpitman(a)redhat.com>:
> standalone.xml is a file, but you can only edit it by shutting down the
> container
> first (and scripting doing this in Puppet is also non-fun).
So with umpteen components, we deliver umpteen config files, that
all need to be tweaked on top of standalone.xml to get something working?
That does not sound right either.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev