In the next versions of the Overlord projects we are doing the following changes:

• Providing support for Wildfly
• Providing SSO support using KeyCloak (currently provided by Overlord-Commons using PicketLink)

One of the benefits of moving to KeyCloak is that it is installed and managed separately, and therefore it simplifies the Overlord installation process - which was primarily related to establishing admin credentials and creating the KeyStore etc infrastructure to support the SSO capability.

The reason for supporting Wildfly, apart from being of general benefit to the community, is that it makes it easier to provide the Overlord projects as Docker images. However, with the current installation process, this creates a large image due to the dependencies (e.g. ant).

This document is intended to discuss the options for simplifying the installation approach, given these two changes, to hopefully make the use of the projects via docker a better experience.

1) Return to use of deployment and configuration folders

KeyCloak is deployed as a war into the standalone/deployments folder, with its configuration (json file) placed in the standalone/configurations folder. In the latest available Overlord project releases, our deployable artifacts are distributed in the modules structure, with the properties defined in the standalone.xml - this was done primarily to support domain mode, however with the focus on cloud/docker containers - preconfigured images may be the most common approach for starting new instances.

From the perspective of RTGov, which now has no requirement to modify the standalone.xml file, it would be easier to return to using deployment/configuration folders. But would be good to be consistent across the overlord projects.

2) Overlay vs Installer

As mentioned above, with RTGov no longer being dependent upon Overlord commons SSO (IDP), it means that it could be installed as an overlay onto EAP and Wildfly. This would simplify distribution in general, and for docker especially.

However SRAMP has a requirement to modify the standalone.xml for various things - modeshape, datasources, hornetq.

QUESTION: Can some/all of these things be handled without transformation?

a) hornetq - rtgov includes its queue/topic configuration in a separate file rtgov/rtgov-epn-hornetq-jms.xml at master · Governance/rtgov · GitHub

b) can the jboss cli be used to configure this info?

If xslt transform required - what is the most effective way to achieve this without necessarily pulling in full ant (within docker).

GB: One solution would be to use ant for non-docker installers, and if only requirement is xslt transform, then from within docker it could be done via cli: http://xml.apache.org/xalan-j/commandline.html

3) Platform specific installation

However the installation is performed, to reduce the size of the distribution we will be providing platform specific installers.

4) Additional module dependencies

RTGov can work with or without switchyard - however if switchyard isn't installed, then some additional drools/mvel related modules are required.

SRAMP depends upon ModeShape and other associated modules.

One approach to this would be to attempt to install the modules, but fail if already present. Another approach may be if an appropriate installer is available (e.g. for ModeShape) that performs the necessary steps?

Once we understand how this post install step will work, we can decide how best to handle the installation as a whole, so that it is performed in a consistent way across the overlord projects and target platforms.

Any thoughts appreciated.

Regards

Gary