config managing JBoss II: The XMLening

[Dick Davies]

I ased a few weeks ago about taming JBoss (AS7.1 / EAP6) with Ansible (1.9.x) -
started in on it this week and I'm hitting the hurdles I'd predicted then
(bit of a war story incoming, feel free to skip to the 'Help!' section):

Fun facts:

* there are 0 playbooks out there that manage JBoss in an idempotent way
* JBoss is actively CM hostile (like, _Jenkins_ hostile)

the gist is JBoss writes its domain.xml whenever it feels like it, so
it's not safe to template that directly. Most guides recommend using
the jboss-cli tool to a) ensure uncorrupted config and b) avoid some
restarts.


I can do that sort of thing with a command: but I'd need to run a
'getter' command: first to check the state of the config, which is a
bit ugly if you're doing lots of changes.

There's a tool called 'jcliff' ( https://github.com/bserdar/jcliff)
which tries to solve this problem,
and has the advantage of being idempotent. Downside is it's docs are
pretty dense, it only supports a subset of the CLIs DMR data
structures , and domain mode support is a hack.

I've spent an hour trying to figure out how to get it to change a log
level and most of that was debugging jcliff rather than JBoss.
At this point its looking uglier than just '2 commands per config
change' plan above.

The ansible-xml library looks like it would do a decent job of
managing config files but as I said JBoss would need to be shut down.
I want this to be safe to run without downtime if no deltas are
needed.

Finally, there are a load of JBoss nerd^W experts here so any config
snippets are likely to be written by them rather than me, so deltas
that support the JBoss DMR are a bonus.

Help!

At this point I think I'm going to have to go with plan A - run a
jboss-cli getter, then a jboss-cli setter if needed
Does anyone know of a module that wraps commands like this?

I've never written an Ansible module before but this seems like it
might be a plan.
If anyone has ever tamed JBoss and wants to tell me the secret, that'd
be cool too :)

Thanks for listening.

[Jeroen Hoekx]

Hi,

On 23 June 2016 at 10:44, Dick Davies <di...@hellooperator.net> wrote:

> Fun facts:
>
> * there are 0 playbooks out there that manage JBoss in an idempotent way
> * JBoss is actively CM hostile (like, _Jenkins_ hostile)
>

> The ansible-xml library looks like it would do a decent job of
> managing config files but as I said JBoss would need to be shut down.
> I want this to be safe to run without downtime if no deltas are
> needed.

We've been managing JBoss with Ansible for about 3 years now in an
idempotent way. I agree that JBoss does not make it easy for a
configuration management system like Ansible.

This is our approach:
- we store the configuration xml (standalone.xml in our case) as an
artifact in our build process
- during deployment we template the xml jinja template in a different location
- we compare it to the current xml config
- when there is a diff, we print it and stop JBoss, move the new
config in place and restart JBoss
- then we deploy the new artifacts using the jboss module

There are two caveats:
- It is important to not deploy through the cli, as this changes the
xml. Filesystem deployments avoid that.
- Keep the xml namespaces up to date with your JBoss version, as JBoss
automatically converts old xmlns declarations to new ones.

It is rather different than your proposed approach, but perhaps this
pragmatic way of configuring JBoss avoids the work you would have to
put in a module.

Greetings,

Jeroen

[Dick Davies]

Thanks Jeroen

glad that works at least - it'd be my fallback position if this
driving jboss-cli
gets ugly. Do you get many false positives on the diffs, or is JBoss OK at
keeping the DOM structure more or less constant (last time I tried something
like that was early tomcat releases, and it seemed to shuffle XML as much as
it could when it synced back)?

> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAAAQQmCBH8H-7S09os6-UKnkTzR-K3aWnhhxqvwMyB8bFRKm8w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

The template module does this by default (the diff if ansible is called with --diff), add a notify handler for the restart and you have all the steps.

> - during deployment we template the xml jinja template in a different location

> - we compare it to the current xml config

> - when there is a diff, we print it and stop JBoss, move the new

> config in place and restart JBoss

----------

Brian Coca

[Josh Smift]

BC> The template module does this by default (the diff if ansible is
BC> called with --diff), add a notify handler for the restart and you have
BC> all the steps.

Right, but with JBoss, the destination file may have been changed since
Ansible pushed it out (because JBoss likes to rewrite its XML files). So
in that case, you can stash a copy of the file somewhere *else*, have the
template module push to there, and notify a handler that then pushes the
template to the real location and does the restart.

-Josh (j...@care.com)

(apologies for the automatic corporate disclaimer that follows)




This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

[Jeroen Hoekx]

Hi,

On 23 June 2016 at 12:40, Dick Davies <di...@hellooperator.net> wrote:

> Do you get many false positives on the diffs, or is JBoss OK at
> keeping the DOM structure more or less constant (last time I tried something
> like that was early tomcat releases, and it seemed to shuffle XML as much as
> it could when it synced back)?

The DOM stays quite OK. I listed the only two conditions we've
encountered in my mail:

* JBoss updates the subsystem xml namespaces when updating, and
rewrites the xml config with the new namespaces. You have to update
your configuration to follow these changes.
* Deployments with the JBoss CLI add content to the XML file. This is
to be avoided.

Greetings,

Jeroen