Any down sides to putting a controller service in the same package as a processor?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Any down sides to putting a controller service in the same package as a processor?

Mike Thomsen
I picked up NIFI-5224, which is for creating a Solr client service, and was
wondering if there are any gotchas or down sides to putting the controller
service in the same NAR as the processors that will use it. Is there any
reason I would want to avoid that?

Thanks,

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Any down sides to putting a controller service in the same package as a processor?

Bryan Bende
That is fine for the CS implementation, the CS API should be in it's own NAR.
On Tue, Sep 25, 2018 at 2:14 PM Mike Thomsen <[hidden email]> wrote:
>
> I picked up NIFI-5224, which is for creating a Solr client service, and was
> wondering if there are any gotchas or down sides to putting the controller
> service in the same NAR as the processors that will use it. Is there any
> reason I would want to avoid that?
>
> Thanks,
>
> Mike
Reply | Threaded
Open this post in threaded view
|

Re: Any down sides to putting a controller service in the same package as a processor?

Mike Thomsen
Thanks. That's what I thought. I may also do that for the Mongo package
because it should cut some space by not duplicating the Mongo driver.

On Tue, Sep 25, 2018 at 2:46 PM Bryan Bende <[hidden email]> wrote:

> That is fine for the CS implementation, the CS API should be in it's own
> NAR.
> On Tue, Sep 25, 2018 at 2:14 PM Mike Thomsen <[hidden email]>
> wrote:
> >
> > I picked up NIFI-5224, which is for creating a Solr client service, and
> was
> > wondering if there are any gotchas or down sides to putting the
> controller
> > service in the same NAR as the processors that will use it. Is there any
> > reason I would want to avoid that?
> >
> > Thanks,
> >
> > Mike
>
Reply | Threaded
Open this post in threaded view
|

Re: Any down sides to putting a controller service in the same package as a processor?

Mark Payne
Mike,

The Mongo Controller Service already exists though, right? You cannot move it into the Processors NAR
after it's already been released. That would change the 'bundle coordinates' for the controller service and
would mean that any flow that uses it is no longer valid and would have to be reconfigured.

Thanks
-Mark


> On Sep 25, 2018, at 3:09 PM, Mike Thomsen <[hidden email]> wrote:
>
> Thanks. That's what I thought. I may also do that for the Mongo package
> because it should cut some space by not duplicating the Mongo driver.
>
> On Tue, Sep 25, 2018 at 2:46 PM Bryan Bende <[hidden email]> wrote:
>
>> That is fine for the CS implementation, the CS API should be in it's own
>> NAR.
>> On Tue, Sep 25, 2018 at 2:14 PM Mike Thomsen <[hidden email]>
>> wrote:
>>>
>>> I picked up NIFI-5224, which is for creating a Solr client service, and
>> was
>>> wondering if there are any gotchas or down sides to putting the
>> controller
>>> service in the same NAR as the processors that will use it. Is there any
>>> reason I would want to avoid that?
>>>
>>> Thanks,
>>>
>>> Mike
>>

Reply | Threaded
Open this post in threaded view
|

Re: Any down sides to putting a controller service in the same package as a processor?

Mike Thomsen
Mark,

Yeah, it already exists, but it is only used by the Mongo lookup service.
Not going to push that change because it would invalidate the service
completely, but I think it would be low impact for Mongo users.

Mike

On Tue, Sep 25, 2018 at 3:35 PM Mark Payne <[hidden email]> wrote:

> Mike,
>
> The Mongo Controller Service already exists though, right? You cannot move
> it into the Processors NAR
> after it's already been released. That would change the 'bundle
> coordinates' for the controller service and
> would mean that any flow that uses it is no longer valid and would have to
> be reconfigured.
>
> Thanks
> -Mark
>
>
> > On Sep 25, 2018, at 3:09 PM, Mike Thomsen <[hidden email]>
> wrote:
> >
> > Thanks. That's what I thought. I may also do that for the Mongo package
> > because it should cut some space by not duplicating the Mongo driver.
> >
> > On Tue, Sep 25, 2018 at 2:46 PM Bryan Bende <[hidden email]> wrote:
> >
> >> That is fine for the CS implementation, the CS API should be in it's own
> >> NAR.
> >> On Tue, Sep 25, 2018 at 2:14 PM Mike Thomsen <[hidden email]>
> >> wrote:
> >>>
> >>> I picked up NIFI-5224, which is for creating a Solr client service, and
> >> was
> >>> wondering if there are any gotchas or down sides to putting the
> >> controller
> >>> service in the same NAR as the processors that will use it. Is there
> any
> >>> reason I would want to avoid that?
> >>>
> >>> Thanks,
> >>>
> >>> Mike
> >>
>
>