Embed SG, and SGSSL as part of this plugin

[jcantrill]

Motivation
During refactoring to try and resolve the transient failure that occurs when we build a TransportClient, I was able to have a NodeClient injected as a dependency. This client was usable for all the calls we require except notifying the SG BackendRegistry that we made a configuration change. The error was a CastClassException of the request that I believe is related to the plugins being loaded by different classloaders. This was the only thing I could find that explains the inability to cast to the same type.

Benefits

• Remove the need to hit the network interface to make calls to the ES API
• Eliminate transport exception
• Eliminate class loading issues

Drawbacks

• SG and SGSSL are no longer separately versioned and updateable from this plugin
• Increased difficulty in packaging for downstream?
• SGAdmin as part of this codebase?
• Missing a required 'registration' of one of the SG or SGSSL plugins?

Requirements

• Modify this plugin to load each dependent plugin when this one starts
• Copy the SGAdmin tool to this repo for use in ACL seeding on server start
• Remove plugin install statements on build of ES image

[jcantrill]

cc @richm @ewolinetz @portante @sosiouxme

[richm]

What does it mean to have SG and SGSSL as part of the openshift-elasticsearch-plugin? Do we add them as sources, and build them from source when we build OEP? Do we include them as jar dependencies in the pom.xml?

We only need to do this in order to notify the SG BackendRegistry? For no other reason? That is, everything else we need to do, we can do without embedding SG?

[portante]

So if somebody invokes the sgadmin utility, how does the sg plugin get notified? And is that notification process different than what this plugin does?

[jcantrill]

What does it mean to have SG and SGSSL as part of the openshift-elasticsearch-plugin? Do we add them as sources, and build them from source when we build OEP? Do we include them as jar dependencies in the pom.xml?

Each plugin has a 'boot' class which ES uses to register the modules and services provided by the plugin. We already declare the jars as dependencies: https://github.com/fabric8io/openshift-elasticsearch-plugin/blob/master/pom.xml#L115. This proposal would take that further in we would also offer the SG services and modules as part of what we provide when our plugin loads (See https://github.com/fabric8io/openshift-elasticsearch-plugin/blob/master/src/main/java/io/fabric8/elasticsearch/plugin/OpenShiftElasticSearchPlugin.java#L30). This would be updated accordingly.

We only need to do this in order to notify the SG BackendRegistry? For no other reason? That is, everything else we need to do, we can do without embedding SG?

The ONLY reason is so we can use a NodeClient to notify SG of a config update. Everything else we can do without embedding. The ONLY alternative would be to tell our plugin where it could find SGAdmin from which we could execute a process to update, which I don't like. SGAdmin is written as a CLI tool in its currrent incarnation.

So if somebody invokes the sgadmin utility, how does the sg plugin get notified? And is that notification process different than what this plugin does?

The plugin gets notified through the transport layer but its in a separate java process. SG is really designed to be used in a static fashion so admins are advised to update the ACL as needed

[richm]

I wonder if there is some really hacky way around this. For example, does Java let you declare/import classes at runtime? That is, we could lazy load com.floragunn.ConfigUpdateRequest just before we use it - perhaps that would allow us to get it from the right class loader? Or maybe there are some ugly hacks we could do with the class loaders, and somehow find the right class loader, and load the class from the right class loader.

[jcantrill]

@richm There is no lazy loading, though maybe we could not package the lib with our plugin since we know we always need to operate with the dependent plugin. I suspect, however, we would get a NoClassDefFound problem (e.g. available at compile but not runtime). There is also a possibility we could use the reflection API to make calls but that would also most likely lead to a NoClassDefFound.

[jcantrill]

fixed by #77