4:19 a.m.
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
5:42 p.m.
Thanks for your feedback Chris, that's also my experience with writing
Puppet modules.
Le 13/02/2015 20:19, Chris Pitman a écrit :
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
11:25 p.m.
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.
12:53 a.m.
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
3367
days inactive
3371
days old
3 comments
3 participants
participants (3)
-
Chris Pitman -
Heiko W.Rupp -
Thomas Segismont