Use HTTP API instead of jboss-cli.sh

[jairojunior]

Based on what I've been discussing with @cpitman by e-mail I have a suggestion that comes with a PoC (Proof of Concept).

Recently I did a jboss_exec (wildfly_cli), jboss_resource (wildfly_resource) and jboss_deploy (wildfly_deploy) implementation using HTTP API (i.e. http://mgmtaddress:9990/management) instead of jboss-cli.sh. It's very simple (does not cover all cases yet) and heavily inspired in jboss_admin: https://github.com/jairojunior/biemond-wildfly/tree/master/lib/puppet

Pros:

• It's faster. [1] Did a simple benchmark with both time and puppet --profile. It's 5-10 times faster in general.
• It's typed. All response already comes in JSON (i.e. no need to parse responses)
• It's a service with an open connection. With jboss-cli you always have to start a new bash session and JBoss connection...

Cons:

• All queries/commands need to be in JSON instead of CLI-syntax, but it's not hard to transform a message in this format: /subsystem=datasources/data-source=AnotherExampleDS:read-resource to this format: { "operation" : "read-resource", "address" : [{"subsystem" : "datasources"}, { "data-source" : "AnotherExampleDS" }]}

What do you guys think? @cpitman @itewk

[1] You can run a simple test in your machine using:

time ./jboss-cli.sh -c --command='/subsystem=datasources/data-source=AnotherExampleDS:read-resource'

time curl -f --digest -u "{user}:{password}" -H Content-Type:\ application/json -d '{ "operation" : "read-resource", "address" : [{"subsystem" : "datasources"}, { "data-source" : "AnotherExampleDS" }]}' "http://localhost:9990/management"

[cpitman]

That is interesting that it is so much faster. The one other con is that the CLI can work with local access, not requiring a username or password for the jboss server. But maybe local access is (1) not needed and (2) the speedup is more important? The greater maintainability by not having to map back and forth to json is appealing as well.

If we do implement this, it would likely be as a second provider (at least until we truly thought the CLI path was dead).

[jmarley]

I am for keeping both. In production environments I generally don't make any management interfaces available outside of the vm. However, if I were running master/slave configuration for puppet, then my slave would be locally running the configurations?

Jason

----- Original Message -----

That is interesting that it is so much faster. The one other con is that the CLI can work with local access, not requiring a username or password for the jboss server. But maybe local access is (1) not needed and (2) the speedup is more important? The greater maintainability by not having to map back and forth to json is appealing as well.

If we do implement this, it would likely be as a second provider (at least until we truly thought the CLI path was dead).

---

Reply to this email directly or view it on GitHub: https://github.com/cpitman/puppet-jboss_admin/issues/68#issuecomment-95694933

[cpitman]

I think we would still default to running the puppet configuration on the same host as EAP, so the management interface could be restricted to the localhost. By master/slave do you mean domain mode? I don't know if anyone has used it yet with this, but I believe you would only apply the puppet configuration to your domain controller.

[itewk]

I am on board for this as a second provider for sure. Especially if it will help speed up my puppet runs which can be up to 15-20 minutes right now.

[jmarley]

I was referring to puppet, but it would be good to do domain mode as well. I just finished a client that used domain mode and had a ton of issues setting up. Although, I'm still skeptical of domain mode, because of the rouge processes still haunt EAP 6.3 release.

Jason

----- Original Message -----

I think we would still default to running the puppet configuration on the same host as EAP, so the management interface could be restricted to the localhost. By master/slave do you mean domain mode? I don't know if anyone has used it yet with this, but I believe you would only apply the puppet configuration to your domain controller.

---

Reply to this email directly or view it on GitHub: https://github.com/cpitman/puppet-jboss_admin/issues/68#issuecomment-95719583

[cpitman]

@itewk How long are your runs when nothing needs to change? I think there might be a simple way to reduce the prefetch time (even for the CLI provider) if that is where we are having problems.

[jairojunior]

@cpitman Module user can set user and password once per manifest with Jboss_cli { username => '', password => '' } . And if security is a concern, we can always try openpgp or something similar...

@jmarley As far as I know, in a master/slave puppet setup, slave has a agent which applies the catalog sent by master. I agree with @cpitman regarding running puppet in the same server that we'll manipulate resoures.

Domain Mode and Puppet aren't a good match. If you already have puppet to apply the same configuration for all JBoss instances (domain slaves), why do you also need Domain Master to coordinate this processes? The only bright side left is regarding having multiple JBoss instances in the same machine, but it happens that you could also easily achieve this with puppet.

@itewk Can you send us the aggregate report of a execution with --profile?

[itewk]

@cpitman

A run where nothing happened.

Notice: Finished catalog run in 154.92 seconds

real 3m9.825s user 2m40.458s sys 0m30.532s