You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Sönke Liebau <so...@opencore.com.INVALID> on 2019/02/08 09:57:39 UTC

State and roadmap for PutElasticsearch processors

Hi,

I've just spent a little time looking over the existing Elasticsearch
processors and digging through the jira for a little history around
what happened so far, and I have a few points that I am unclear on.
Maybe someone can clarify this for me?

Are there any plans to change the PutElasticsearch processor to use
the official High-(or Low-) Level Rest client instead of building the
Rest requests "manually"?

Is there a versioning strategy going forward? I think we can probably
expect Elasticsearch breaking compatibility every now and then,
especially with major versions. Will there be a new PutElasticsearch7
processor for the next major version in case that happens?
Would it be an alternative to handle this internally, query the
version we are running against and then have different versions of the
library shaded / build different requests as necessary?

Not proposing anything here, just trying to get up to speed :)

Best regards,
Sönke

Re: State and roadmap for PutElasticsearch processors

Posted by Mike Thomsen <mi...@gmail.com>.
Sonke,

The main ElasticSearch bundle should easily support ElasticSearch in most
cases through v6. The only question at this point will be updating it to
support the removal of types around the release of v7.

The new REST API NAR bundle that provides JsonQueryElasticSearch is built
on client services that use the official API. I'm working that, but there's
no official timeline on when it will be a full CRUD replacement for the
others.

I would recommend avoiding the "v5 bundle" because it uses the transport
protocol, and around Elastic v7 that will become a private API in favor of
a pure REST approach.

Thanks,

Mike

On Fri, Feb 8, 2019 at 4:58 AM Sönke Liebau
<so...@opencore.com.invalid> wrote:

> Hi,
>
> I've just spent a little time looking over the existing Elasticsearch
> processors and digging through the jira for a little history around
> what happened so far, and I have a few points that I am unclear on.
> Maybe someone can clarify this for me?
>
> Are there any plans to change the PutElasticsearch processor to use
> the official High-(or Low-) Level Rest client instead of building the
> Rest requests "manually"?
>
> Is there a versioning strategy going forward? I think we can probably
> expect Elasticsearch breaking compatibility every now and then,
> especially with major versions. Will there be a new PutElasticsearch7
> processor for the next major version in case that happens?
> Would it be an alternative to handle this internally, query the
> version we are running against and then have different versions of the
> library shaded / build different requests as necessary?
>
> Not proposing anything here, just trying to get up to speed :)
>
> Best regards,
> Sönke
>