Re: Proposal for ElasticSearch support

2019-05-08 Thread Mike Thomsen
Elasticsearch 7.0 is out, and I updated the REST API bundle to have preliminary support for it. Also removed the high level rest client in favor of using only the low level one per some documentation provided in the PR. So going forward that bundle should be a lot more future-proof than the

Re: Proposal for ElasticSearch support

2019-02-20 Thread Mike Thomsen
Matt, I think we could proceed like this: 1. Deprecate v2 and v5 in 1.10 2. Remove v5 from the assembly in 1.11. 3. Announce that v2 will be removed from the assembly in 1.13 or 1.14--whichever coincides with the end of Q4/early Q1 2020. That gives us a whole year to work on the REST API bundle

Re: Proposal for ElasticSearch support

2019-02-20 Thread Mike Thomsen
Normally, I would agree with that, but ES is very popular so I wanted to give users a chance to shout "hey don't do that because [reason]." On Wed, Feb 20, 2019 at 10:27 AM Joe Witt wrote: > ...probably for dev thread but I am starting to think we should just start > removing certain nars from

Re: Proposal for ElasticSearch support

2019-02-20 Thread Otto Fowler
Maybe this would be a nice first use case for that strategy, we can wrap it up from top to bottom. On February 20, 2019 at 10:27:40, Joe Witt (joe.w...@gmail.com) wrote: ...probably for dev thread but I am starting to think we should just start removing certain nars from the convenience

Re: Proposal for ElasticSearch support

2019-02-20 Thread Joe Witt
...probably for dev thread but I am starting to think we should just start removing certain nars from the convenience build/assembly and documenting it in the migration guide for users that need those. We can then show them how to use the hot loading/etc.. Thanks On Wed, Feb 20, 2019 at 10:04

Re: Proposal for ElasticSearch support

2019-02-20 Thread Matt Burgess
+1 for deprecating both the v2 and v5 (those using a transport client) components in 1.10, to be removed later. What do you think about refactoring the top-level ES bundle into 3 (v2, v5, REST) and creating profiles (deactivated by default) for the v2 and v5 bundles? I guess that could wait until

Re: Proposal for ElasticSearch support

2019-02-20 Thread Otto Fowler
I think that there should be specific documentation guidance around this, like “Picking the right Elasticsearch Processors” to avoid issues. On February 20, 2019 at 08:02:18, Mike Thomsen (mikerthom...@gmail.com) wrote: I would like to mark the v5 Elastic bundle as deprecated in 1.10. Per

Proposal for ElasticSearch support

2019-02-20 Thread Mike Thomsen
I would like to mark the v5 Elastic bundle as deprecated in 1.10. Per Elastic's official guidelines, the transport API--which it uses--is deprecated in Elastic 7 and to be removed from at least public accessibility in Elastic 8.