Request for opinion: Instancable jboss-standalone

[sspreitzer]

Hi all

Currently I am working on a Red Hat customer project, where I can provide code back via OpenSource licensing. The requirements lead to instantiate jboss-standalone. At the current point we have to decide whether to extend coi/jboss with this functionality or the create an own module. Can you please kindly provide feedback to me, whether you would be generally accepting and later merging this feature enhancement (given that it would fulfill your contribution guidelines)?

PS.: Please provide feedback as soon as possible.

Kind regards Sascha

CC: @klenkes74

[Cosaquee]

Hello !

Thanks for your interest in our module coi/jboss. We are a bit confused about your question. Can you tell us what do you mean by:

instantiate jboss-standalone

Our module, right now handles installation and management of jboss middleware products in standalone mode pretty well in our opinion. For example:

# this will install and run jboss (by default wildfly) in standalone mode
include jboss

In terms of cooperation between contributors and us. We will gladly accept all contributions to our projects if they fulfill contribution guidelines.

Feel free to open new tasks or issues with specific questions or change requests. If you can provide code in pull requests we will be glad and eager to provide any feedback. We will evaluate each pull requests independently for compliance with contribution guidelines, code quality and overall code style. If we decide that your contributions are ok we will handle merging, releasing and publishing it to Puppet Forge.

[sspreitzer]

Hi again

Our module, right now handles installation and management of jboss middleware products in standalone mode pretty well in our opinion.

Yes for this reason we are interested in this module.

In our use case we are working to instead of using Domains to create instantiable JBoss standalone. Wich would reside in a specific or general path. An init script would be created (or systemd service) that would source any runtime parameters and start and control the respective instance.

[root@xyz myinstance]# pwd
/opt/example/myinstance
[root@xyz myinstance]# ls -al
insgesamt 28
drwxr-xr-x. 7 root root 4096 20. Jan 05:13 .
drwxr-xr-x. 3 root root 4096 20. Jan 05:10 ..
drwxr-xr-x. 2 root root 4096 20. Jan 05:13 configuration
drwxr-xr-x. 2 root root 4096 20. Jan 05:13 deployments
drwxr-xr-x. 2 root root 4096 20. Jan 05:13 lib
drwxr-xr-x. 2 root root 4096 20. Jan 05:13 log
drwxr-xr-x. 2 root root 4096 20. Jan 05:13 tmp
[root@xyz myinstance]# ls -al /etc/init.d/myinstance 
-rwxr-xr-x. 1 root root 0 20. Jan 05:11 /etc/init.d/myinstance

What do you think about this proposal and would you be okay to accept such an enhancement? I am asking before we put efforts in writing the code to decide whether or not to enhance your jboss module or to write a new one explicitly for this use case..

Kind regards Sascha

[cardil]

This looks like a really cool feature, if it will be done right! I was thinking about it in the past.

Our module right now supports only one instance per machine. This is due to limitation of single instance of main jboss class. To achieve multi instances in the same host there should be major refactoring needed. I'm thinking about a define like:

jboss::instance { 'wildfly8':
  product => 'wildfly',
  version => '8.0.0.Final',
}
jboss::instance { 'wildfly9':
  product => 'wildfly',
  version => '9.0.0.Final',
}

we don't use default jboss class in this example and we need to introduce a parameter to all defines like instance => 'default' to know at which instance it should run against.

As I was saying, this feature was considered by me, but postponed due to it's complexity. :-/

Important thing for us is to leave default behavior simple. After your changes this module should still be easy to use for beginners for ex.: to install and run jboss in single line of code like include jboss. Basically the examples in tests/ directory and in Wiki pages should be still valid (with minor changes). I spoke about it in this presentation: http://slides.com/cardil/reusable-puppet-module-development-and-testing

Please consider thinking how to implement this and propose here your ideas before doing some real coding. In that way we could avoid misunderstanding, and also we could help with designing this as it's a major change.

[sspreitzer]

Hi again

Thank you for the detailed outline.

To achieve multi instances in the same host there should be major refactoring needed.

Unfortunately we can not put efforts in refactoring your module but are in urge need to create the instancable standalone. We would proceed in creating a different module.

Thank you for clarification!

[cardil]

That's a bummer :-/ But, I understand your reasons. Could you link your module here, for a reference, when it's done?