Future-proofing custom bundles that use the Record API

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

Future-proofing custom bundles that use the Record API

Mike Thomsen
Any recommendations or best practices for making custom bundles that use
the record API not tied to a specific version of NiFi? We can obviously
just rebuild when we do an upgrade, but I'm curious if anyone has worked on
this so that ops folks can do upgrades without having to coordinate with
developers just to make sure the custom bundles don't break.

Thanks,

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Future-proofing custom bundles that use the Record API

Bryan Bende
The record API is part of nifi-record-serialization-services which
gets bundled with nifi-standard-services-api. I think when we get the
extension registry working we should be able to disconnect the
releases of nifi framework from all of the other bundles, instead of
the current situation where every time we do a release all of the
bundles get released even if there are no new changes to the bundle.
So hopefully it would make it easier to upgrade nifi itself without
having to touch the other bundles.

Besides that I would expect that there is a test/integration
environment where you upgrade nifi and test all your flows with your
custom bundles before upgrading production.

On Sat, Jan 26, 2019 at 7:21 AM Mike Thomsen <[hidden email]> wrote:

>
> Any recommendations or best practices for making custom bundles that use
> the record API not tied to a specific version of NiFi? We can obviously
> just rebuild when we do an upgrade, but I'm curious if anyone has worked on
> this so that ops folks can do upgrades without having to coordinate with
> developers just to make sure the custom bundles don't break.
>
> Thanks,
>
> Mike