Re: [DISCUSS] Elasticsearch Http using Jest

sjudeng <sju...@...>

I think JanusGraph should end formal support for 1.x, though it would be great if users could still have the ability to use it (even if unsupported/tested) via your Jest-based implementation. For one I'm biased as the author of the above PR, which does drop support for 1.x and I'd really like to see get merged before moving forward. More importantly though in working through updates to support 5.x I was happy to find the Elasticsearch distribution zip artitfacts available for 2.x and 5.x (but not 1.x) in Maven central. The availability of the ES distribution for 2.x and 5.x artifacts enables their automated use in unit tests and in building JanusGraph releases (e.g. for use in running embedded ES instances). This allows for JanusGraph to remove the hacked elasticsearch and scripts from janusgraph-dist and also avoids the JarHell issues both during testing and when starting embedded ES instances. This improves maintainability and stability.

The proposed update to support HTTP ES client via Jest sounds great to me. Personally I think it would be nice to avoid adding compability shims to enable the cross-version support. But either way I do want to make sure that testing rigor is not lost in the updates. I think formal/full support for any ES version should require that the full janusgraph-es test suite can be run (automatically) against that version and corresponding embedded ES instances for that version are supported through janusgraph-dist. I have tested this works for 2.x and 5.x, but I'm not sure that it would work for 1.x ... at least not without really going backwards/hacking project configuration.

If you're able to make this work to support full test suite/embedded instances across the three versions cleanly, that'd be great. Otherwise I'd propose docs would be updated to indicate that JanusGraph fully supports 2.x and 5.x but that 1.x is no longer maintained (read "tested") though can still be used if necessary through the relevant Jest-jar change. It seems to me this would be sufficient. JanusGraph has already started down the road of making breaking changes in the coarse of moving beyond Titan, including dropping support for old versions of HBase and updating TinkerPop, which because of the underlying Spark update would require an update to users compute clusters.

On Thursday, March 2, 2017 at 9:40:07 AM UTC-6, Keith Lohnes wrote:
I started some conversation over at, and Jason Plurad suggested I move that over here. 

I have some code that's been used in a Titan deployment using the apache licensed Jest ES http client. There was some discussion in that PR about whether to continue to support the Transport/node client in there as well.

The key points of the conversation there
1. Versions to support (1.x, 2.x, 5.x)

   With the Jest client, we could support all three pretty easily. 1 vs 2.x and 5.x would be changing the .jar out.  There's some open PRs in the Jest repo that need to get merged for 5.x support, but once those are and we update the jar version, we'd be able to support 5.x. Maintaining 1.x support for a little while would be nice for people with production Titan instances, as Adam Phelps pointed out. 1.x and 2.x could use the same code, they just need different jars.

2. HTTP vs Transport/Node
    I think in #92 there's a mention of Transport being deprecated. My first instinct is to say that Janus should mark Transport/Node as deprecated and continue to support Transport/Node clients until a major version release at which point support could be removed.  I have some work done to split out the Transport/Node clients from the Http client, and make for an easy removal once that decision has been made.

Join { to automatically receive all group messages.