You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Mike Thomsen <mi...@gmail.com> on 2018/06/10 11:46:10 UTC
Should the elastic search client service impl get renamed before 1.7?
The current implementation uses the last stable release of the 5.X client
from Elastic, and 6.X is already mature so we'll need to be able to have
room to create a new implementation copy that uses that client if there are
things we have to change between them. So does it make sense to throw in a
new ticket to rename the service to something that indicates that this
implementation is officially for 5.X? As of 1.6 I think only one processor,
JsonQueryElasticSearch, uses it so not many uses would likely be impacted
yet.
Thanks,
Mike
Re: Should the elastic search client service impl get renamed before 1.7?
Posted by Bryan Bende <bb...@gmail.com>.
Lets make sure this is mentioned in the migration notes wiki for 1.7.0
since it will create a ghost component for existing flows that have
the ES service with the original name.
On Mon, Jun 11, 2018 at 9:16 AM, Mike Thomsen <mi...@gmail.com> wrote:
> Should mention that I did not check the L&N for the ES 6.X version. That
> needs to be reviewed as part of the PR.
>
> On Mon, Jun 11, 2018 at 7:54 AM Mike Thomsen <mi...@gmail.com> wrote:
>
>> https://github.com/apache/nifi/pull/2782
>>
>> Renamed the service and added a clone for 6.X. The integration tests use a
>> Maven ES plugin that downloads ES, bootstraps it with test data and runs
>> the integration tests against that. The 6.X version uses the latest stable
>> build (6.2.4) and passed all integration tests.
>>
>> On Sun, Jun 10, 2018 at 11:35 AM Mark Payne <ma...@hotmail.com> wrote:
>>
>>> I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t
>>> make breaking changes, 7.x may. And I’d rather not have an
>>> ElasticSearchClient that works for 5.x and 6.x and then an
>>> ElasticSearchClient_7 that deals with 7. It makes it look like the simply
>>> named ElasticSearchClient is generic and will work with any version. This
>>> is what we did with the PublishKafka* processors and it has only caused
>>> confusion.
>>>
>>> Sent from my iPhone
>>>
>>> > On Jun 10, 2018, at 8:20 AM, Mike Thomsen <mi...@gmail.com>
>>> wrote:
>>> >
>>> > I think types are required in 5.X and optional in 6.X. By 8.X types are
>>> > going to be firmly eliminated, so that's at least one area of research
>>> that
>>> > needs to be done I suppose.
>>> >
>>> > On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <sivaprasanna246@gmail.com
>>> >
>>> > wrote:
>>> >
>>> >> I feel if the upgrade from 5.x to 6.x client doesn't introduce any
>>> breaking
>>> >> changes, we can continue with the name that we are having now.
>>> >>
>>> >> -
>>> >> Sivaprasanna
>>> >>
>>> >> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> The current implementation uses the last stable release of the 5.X
>>> client
>>> >>> from Elastic, and 6.X is already mature so we'll need to be able to
>>> have
>>> >>> room to create a new implementation copy that uses that client if
>>> there
>>> >> are
>>> >>> things we have to change between them. So does it make sense to throw
>>> in
>>> >> a
>>> >>> new ticket to rename the service to something that indicates that this
>>> >>> implementation is officially for 5.X? As of 1.6 I think only one
>>> >> processor,
>>> >>> JsonQueryElasticSearch, uses it so not many uses would likely be
>>> impacted
>>> >>> yet.
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Mike
>>> >>>
>>> >>
>>>
>>
Re: Should the elastic search client service impl get renamed before 1.7?
Posted by Mike Thomsen <mi...@gmail.com>.
Should mention that I did not check the L&N for the ES 6.X version. That
needs to be reviewed as part of the PR.
On Mon, Jun 11, 2018 at 7:54 AM Mike Thomsen <mi...@gmail.com> wrote:
> https://github.com/apache/nifi/pull/2782
>
> Renamed the service and added a clone for 6.X. The integration tests use a
> Maven ES plugin that downloads ES, bootstraps it with test data and runs
> the integration tests against that. The 6.X version uses the latest stable
> build (6.2.4) and passed all integration tests.
>
> On Sun, Jun 10, 2018 at 11:35 AM Mark Payne <ma...@hotmail.com> wrote:
>
>> I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t
>> make breaking changes, 7.x may. And I’d rather not have an
>> ElasticSearchClient that works for 5.x and 6.x and then an
>> ElasticSearchClient_7 that deals with 7. It makes it look like the simply
>> named ElasticSearchClient is generic and will work with any version. This
>> is what we did with the PublishKafka* processors and it has only caused
>> confusion.
>>
>> Sent from my iPhone
>>
>> > On Jun 10, 2018, at 8:20 AM, Mike Thomsen <mi...@gmail.com>
>> wrote:
>> >
>> > I think types are required in 5.X and optional in 6.X. By 8.X types are
>> > going to be firmly eliminated, so that's at least one area of research
>> that
>> > needs to be done I suppose.
>> >
>> > On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <sivaprasanna246@gmail.com
>> >
>> > wrote:
>> >
>> >> I feel if the upgrade from 5.x to 6.x client doesn't introduce any
>> breaking
>> >> changes, we can continue with the name that we are having now.
>> >>
>> >> -
>> >> Sivaprasanna
>> >>
>> >> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
>> >> wrote:
>> >>
>> >>> The current implementation uses the last stable release of the 5.X
>> client
>> >>> from Elastic, and 6.X is already mature so we'll need to be able to
>> have
>> >>> room to create a new implementation copy that uses that client if
>> there
>> >> are
>> >>> things we have to change between them. So does it make sense to throw
>> in
>> >> a
>> >>> new ticket to rename the service to something that indicates that this
>> >>> implementation is officially for 5.X? As of 1.6 I think only one
>> >> processor,
>> >>> JsonQueryElasticSearch, uses it so not many uses would likely be
>> impacted
>> >>> yet.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Mike
>> >>>
>> >>
>>
>
Re: Should the elastic search client service impl get renamed before 1.7?
Posted by Mike Thomsen <mi...@gmail.com>.
https://github.com/apache/nifi/pull/2782
Renamed the service and added a clone for 6.X. The integration tests use a
Maven ES plugin that downloads ES, bootstraps it with test data and runs
the integration tests against that. The 6.X version uses the latest stable
build (6.2.4) and passed all integration tests.
On Sun, Jun 10, 2018 at 11:35 AM Mark Payne <ma...@hotmail.com> wrote:
> I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t
> make breaking changes, 7.x may. And I’d rather not have an
> ElasticSearchClient that works for 5.x and 6.x and then an
> ElasticSearchClient_7 that deals with 7. It makes it look like the simply
> named ElasticSearchClient is generic and will work with any version. This
> is what we did with the PublishKafka* processors and it has only caused
> confusion.
>
> Sent from my iPhone
>
> > On Jun 10, 2018, at 8:20 AM, Mike Thomsen <mi...@gmail.com>
> wrote:
> >
> > I think types are required in 5.X and optional in 6.X. By 8.X types are
> > going to be firmly eliminated, so that's at least one area of research
> that
> > needs to be done I suppose.
> >
> > On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <si...@gmail.com>
> > wrote:
> >
> >> I feel if the upgrade from 5.x to 6.x client doesn't introduce any
> breaking
> >> changes, we can continue with the name that we are having now.
> >>
> >> -
> >> Sivaprasanna
> >>
> >> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
> >> wrote:
> >>
> >>> The current implementation uses the last stable release of the 5.X
> client
> >>> from Elastic, and 6.X is already mature so we'll need to be able to
> have
> >>> room to create a new implementation copy that uses that client if there
> >> are
> >>> things we have to change between them. So does it make sense to throw
> in
> >> a
> >>> new ticket to rename the service to something that indicates that this
> >>> implementation is officially for 5.X? As of 1.6 I think only one
> >> processor,
> >>> JsonQueryElasticSearch, uses it so not many uses would likely be
> impacted
> >>> yet.
> >>>
> >>> Thanks,
> >>>
> >>> Mike
> >>>
> >>
>
Re: Should the elastic search client service impl get renamed before
1.7?
Posted by Mark Payne <ma...@hotmail.com>.
I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t make breaking changes, 7.x may. And I’d rather not have an ElasticSearchClient that works for 5.x and 6.x and then an ElasticSearchClient_7 that deals with 7. It makes it look like the simply named ElasticSearchClient is generic and will work with any version. This is what we did with the PublishKafka* processors and it has only caused confusion.
Sent from my iPhone
> On Jun 10, 2018, at 8:20 AM, Mike Thomsen <mi...@gmail.com> wrote:
>
> I think types are required in 5.X and optional in 6.X. By 8.X types are
> going to be firmly eliminated, so that's at least one area of research that
> needs to be done I suppose.
>
> On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <si...@gmail.com>
> wrote:
>
>> I feel if the upgrade from 5.x to 6.x client doesn't introduce any breaking
>> changes, we can continue with the name that we are having now.
>>
>> -
>> Sivaprasanna
>>
>> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
>> wrote:
>>
>>> The current implementation uses the last stable release of the 5.X client
>>> from Elastic, and 6.X is already mature so we'll need to be able to have
>>> room to create a new implementation copy that uses that client if there
>> are
>>> things we have to change between them. So does it make sense to throw in
>> a
>>> new ticket to rename the service to something that indicates that this
>>> implementation is officially for 5.X? As of 1.6 I think only one
>> processor,
>>> JsonQueryElasticSearch, uses it so not many uses would likely be impacted
>>> yet.
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>
Re: Should the elastic search client service impl get renamed before 1.7?
Posted by Mike Thomsen <mi...@gmail.com>.
I think types are required in 5.X and optional in 6.X. By 8.X types are
going to be firmly eliminated, so that's at least one area of research that
needs to be done I suppose.
On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <si...@gmail.com>
wrote:
> I feel if the upgrade from 5.x to 6.x client doesn't introduce any breaking
> changes, we can continue with the name that we are having now.
>
> -
> Sivaprasanna
>
> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
> wrote:
>
> > The current implementation uses the last stable release of the 5.X client
> > from Elastic, and 6.X is already mature so we'll need to be able to have
> > room to create a new implementation copy that uses that client if there
> are
> > things we have to change between them. So does it make sense to throw in
> a
> > new ticket to rename the service to something that indicates that this
> > implementation is officially for 5.X? As of 1.6 I think only one
> processor,
> > JsonQueryElasticSearch, uses it so not many uses would likely be impacted
> > yet.
> >
> > Thanks,
> >
> > Mike
> >
>
Re: Should the elastic search client service impl get renamed before 1.7?
Posted by Sivaprasanna <si...@gmail.com>.
I feel if the upgrade from 5.x to 6.x client doesn't introduce any breaking
changes, we can continue with the name that we are having now.
-
Sivaprasanna
On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <mi...@gmail.com>
wrote:
> The current implementation uses the last stable release of the 5.X client
> from Elastic, and 6.X is already mature so we'll need to be able to have
> room to create a new implementation copy that uses that client if there are
> things we have to change between them. So does it make sense to throw in a
> new ticket to rename the service to something that indicates that this
> implementation is officially for 5.X? As of 1.6 I think only one processor,
> JsonQueryElasticSearch, uses it so not many uses would likely be impacted
> yet.
>
> Thanks,
>
> Mike
>