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 <mikerthom...@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 <mikerthom...@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 <marka...@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 <mikerthom...@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 <sivaprasanna...@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 <mikerthom...@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 >>> >>> >>> >> >>> >>
