I’ve submitted a PR that contains enhancements to the JBoss module that have been kicked around in the JBoss/Ansible community (there are dozens of us!!). If someone can take a look and give me some feedback, I’d be most grateful. Ansible has the potential to help a lot of JBoss shops that want to tighten up their development cycle but aren’t ready to drink the DevOps kool-aid yet. In order to unlock that potential, we need more features in the JBoss module.
At this juncture, the JBoss module only supports deployment/undeployment via the filesystem using the deployment scanner (a JBoss service that scans a particular fs directory for deployable files and deploys them). This means it either adds or removes a deployment artifact (e.g., a .war file) to a specified deployment directory. In older versions of JBoss, this was the only way to do hot deployments, but starting with JBoss 7, users have the option of using a provided CLI as well as an HTTP interface in addition to the fs method. The fs method is not recommended for production use.
So as a first step towards enhancing the JBoss module, I’ve added support for deploying via the HTTP API and the CLI. Some of us have also talked about a facts module, possibly using jolokia to gather detailed data on JBoss environments. A jolokia module could also extend deployment capabilities to other Java environments, since it’s not specific to JBoss.
I was discussing this PR at ansible-devel (IRC) instead of the devel list, but I believe we could contribute to each other work or even combine efforts. (:
Basically, a Working Group is a simple way of putting some structure
around specific project efforts. Gets you your own IRC channel (if you
want it) and some project/wiki space in the ansible/community repo.
It's a good lightweight governance mechanism for working together on
specific projects.
If you're interested, here's how to start one -- dead simple, by design:
This sounds like a great idea. Ideas are floating around the community somewhat aimlessly right now, and it would be great if we had a forum to coordinate my work with the great work that Jairo and others are doing. It would also be great to have a place to send Ansible/JBoss users for info/questions/gripes/etc.
Here’s a wrinkle we might want to think about: the community project formerly known as JBoss is now Wildfly, and JBoss is sort of a Red Hat sub-brand assigned to various supported (i.e. paid) middleware/app dev products. To my knowledge, no upstream community project carries the JBoss brand. To avoid confusion, we might want to think about calling the WG something like the Wildfly working group, even if we plan to support pre-Widlfly versoins of JBoss AS (i.e. 7.x and earlier), which I think we should. But I’m not married to that idea. I’d love to hear anyone else’s thoughts.
If we can agree on a name, and Jairo, if you’re interested & available, I’ll go ahead and create a request to form the working group with you and I as members, and we can start coordinating work. I’ll also search out JBoss-related issues and PR’s for other potential members.
I used JBoss name because of existing modules and I believe JBoss brand is more popular than Wildfly. More popular means more users, so more contributors, feedback and etc… (:
One important thing to notice is that Wildfly is known as the upstream project of JBoss EAP, but other projects that use JBoss’ Architecture and even carry JBoss name in their productized version such as Keycloak (Red Hat SSO), Infinispan (JDG), Teiid (JDV) and apiman can also be managed through Management API or JBoss-CLI. You just can’t deploy applications to them.
So, they’re not Wildfly (Infinispan, Teiid, apiman) but “are JBoss”, and in special cases they’re neither (Keycloak).
I’ve created a creation request for the JBoss WG. Once we have the IRC channel, we should do an initial planning meeting via IRC, so let’s start thinking about when would be a good time for that. For starters, we should figure out which time zone everyone is in. I’m US/Eastern (UTC-4:00).
Again, thanks for suggesting and facilitating the creation of this group. Can you provide any guidance on where to go from here, besides what’s already covered in the docs? Specifically, is there a process we can follow to get PR’s reviewed and ultimately merged?
Again, thanks for suggesting and facilitating the creation of this group.
Can you provide any guidance on where to go from here, besides what's
already covered in the docs? Specifically, is there a process we can follow
to get PR's reviewed and ultimately merged?
In general, the process for getting module PRs reviewed and merged is
ultimately the same -- get the PR Bot to give you the thumbs up on all
tests, and get the maintainer of the module to agree that the PR is worth
merging.
The tricky thing can be getting everyone on the same page on those things
in a timely manner. The async nature of distributed development can be a
significant hindrance.
IMO, that's where Working Groups are valuable: they provide structure for a
group of people who are dedicated to solving these problems, in the same
place at the same time, to shorten the feedback loops.
So I would say:
* make sure the owners of the various JBoss modules are in your working
group;
* make sure to set up regular IRC meetings when they can all be present to
review PRs;
* make sure everyone is hanging out in the #ansible-jboss channel so that
you have quick/easy access to each other.
The Working Groups really aren't that complicated. They're just a very
simple way of encouraging people to work together, with just a little bit
of infrastructure/process to help.
Take a look at how the Windows and Testing Working Groups operate. I feel
like they're setting the standard right now.
How does everyone feel about doing our first meeting an hour before the core team meeting on Tuesday? This would be 3pm for Jairo, 2pm for me, 1pm for Antonio.