Re: [Hawkular-dev] About configuration

Hey guys, I'm a bit late to the party, but here are my two cents as someone who has spent months integrating Puppet with EAP 6 (https://github.com/cpitman/puppet-jboss_admin). > >/ > 3) Why not try to have all our configuration set in standalone.xml? If we />/ />/ > are going to be deployed in Wildfly, it would be nice to have everything /> >/ > (not just our config, but the config for the wildfly subsystems too) in /> >/ > one place. This also allows us to piggyback on jboss-cli - we simply use >/>/ > the jboss-cli to have a cmdline interface to our configuration. >/>/ >/>/ I'd rather keep our apps config out the Wildfly config. / > What is your reasoning for wanting to keep our apps config out of Wildfly config? > The reason why I say it would be nice to use standalone.xml for our config is: > 1) all configuration, for everything, is in one place. Remember JBoss 4, with all their many .xml config files? It was hard to manage, which is one reason why they went to a single .xml file (though, granted, I believe they are thinking about making it possible to import .xml files into the main config - don't know if that's available yet). > 2) It gives us, for free, a CLI - we don't have to write and maintain one. If everything is in standalone.xml, we can use the JBoss CLI to look at our config and change it along with the rest of the wildfly subsystems. The CLI is a painful way to automate deployment using declarative tools like Puppet. If the goal is to make it easy to configure and deploy, files are superior. Yes, 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). Not to say it impossible. The module I linked above could be used, but it is still vastly more complicated than a solution that just needs a templated config file. > 3) If our components consist of Wildfly Extensions, then this is how you configure that extension. So it would be natural to have all config (for the extension and the other pieces of the component) in the same place. > 4) Address and port assignments. Right now, standalone.xml allows you to define socket binding groups - allowing a "one stop shop" to define all your port bindings. Adjusting the port-offset provides a nice way to easily offset ports so you can run multiple components on the same box. If we have different configs (that need to specify hostnames/ports), we now have multiple places where this is configured - thus opening up to possible conflicts plus just a pain to have to now go to different places to configure bindings. The port bindings in one place is nice for manageability. > The one negative of this approach is if our components can run outside of being embedded in Wildfly, we lose all of the above. We would need our own configuration mechanism (and CLI) if we can run outside of WildFly. > But I see alot of positives for putting our subsystem configuration in with the rest of WildFly subsystem configs. Chris Pitman Architect, Red Hat Consulting DevOps Community of Practice Manager _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev