3 Replies Latest reply on Jun 30, 2014 12:12 PM by objectiser

Making overlord sub-project installers consistent

objectiser Jun 6, 2014 5:07 AM

Wanted to discuss how we can make the installers for each sub-project more consistent - which should then help when providing an 'overlord' installer.

1) On-demand or full distribution

Originally I believe the sramp/dtgov installer downloaded content during installation - kept the installer size small, but relied on (a) internet access during installation, and (b) may be prone to temporary or permanent issues with artifacts being unavailable.

More recently the distributions have included the required components, so potentially can be installed offline. Is this still the preferred route?

2) Single or separate distributions

We are now supporting multiple platforms - technically only EAP and Fuse/Fabric at this stage, but indirectly (atleast for sramp/dtgov) we have tomcat and jetty.

The issue is, do we have a single distribution with all platform content and the user selects target when running installer, or should we have a distribution per target platform?

Generally users will only be interested in a single target platform, so may not be happy downloading a distribution that is significantly larger than it needs to be, due to including support for multiple platforms. However, looking at the UI wars and main server war for RTGov, they are only 20 to 30Mb each, so potentially this is not an issue.

3) Installation target managed in commons installer

The installer should offer the option (where possible) to obtain the target platform/version, or use an existing location where an environment has already been setup.

Currently RTGov (for EAP) just assumes the environment already exists, with JBOSS_HOME identifying the location. SRAMP/DTGov can download the environment or reference existing (except for EAP as cannot be downloaded without signing agreement).

It would seem better to move this functionality into the commons installer, so each sub-project could just expect an appropriate environment to have been setup/identified? One caveat though - some sub-projects may not be supported on all platforms, so we would need to identify the supported platforms (possibly the commons installer could mark the others greyed out, or just not list them). This will also need to be considered for the overlord installer - how to deal with matrix of sub-projects to supported platforms.

Issue for RTGov - it may also require the option to install switchyard in these environments. This is where making users responsible for setting up the target environment has benefits - they can decide what is required, before installing governance. One solution would be to just offer the base platforms through the common installer, and they have to add extras after (and switchyard would be counted as an extra)?

Thoughts appreciated. Ideally it would be good to get this sorted for the coming final release, but needs to be coordinated to manage the impact on the individual installers. Also would be good to allow any interactive options to be specifiable on the command line, to enable automated installation (e.g. for automated testing purposes).

1. Re: Making overlord sub-project installers consistent

eric.wittmann Jun 6, 2014 7:41 AM (in response to objectiser)

1) I have no strong preference here. The reason to have a binary distribution that is entirely self contained is for users who need to install on a server machine that has limited access to the internet. For the community projects, it seems like there may not be a strong need for this. However, it would probably be easier to continue with our current approach of including the binaries in the distribution. Note that the s-ramp installer may still download a handful of JARs when installing in Tomcat/Jetty (I need to check). This is happening more because it was quicker to implement at the time than from any specific desire for the behavior.

2) Single distribution is easier for us to maintain I think. If we split up the distribution we have to maintain multiple assembly configs (at the least) as well as everything else we already maintain. I don't see the download size as being large enough to warrant the split.

3) +1 on this - currently the platform choice code is copied in both tomcat and dtgov. Should definitely be moved to commons. I think keeping the ability to download tomcat and jetty is nice. It's not hard to maintain (just few lines of ant code) and it makes installing *something* quickly really really easy.
Actions
2. Re: Making overlord sub-project installers consistent

brmeyer Jun 30, 2014 12:02 PM (in response to objectiser)

1.) No real preference from me either. There are pros and cons to both, but I don't think the offline distro is big enough to necessarily worry about.

2.) Ditto. Easier to maintain w/ a negligible distro size.

3.) If I'm understanding what you're asking, this overlaps with what I was thinking for the integration tests. A new ant script would have the ability to download the applicable Tomcat, Jetty, or Fuse distro, rather than requiring it to already exist. But, instead, moving this into the installer itself makes a lot of sense, at least as an option. EAP is still the outlier. +1 for pulling as much of that into commons as possible.
Actions
3. Re: Making overlord sub-project installers consistent

objectiser Jun 30, 2014 12:12 PM (in response to brmeyer)

Ok to summarise then:
- we stick with the full single distribution approach
- selection of installation target and management of obtaining ref to existing location, or downloading a new environment (where possible), will be handled by the installer.

Other requirement is to make the commons installer, and the individual project installers, operate from command line arguments as well as interactive - to make it easier for use in automated testing scenarios as well as from a IzPack installer.
Actions

Go to original post