Re: [DISCUSS] Bringing MiNiFi into NiFi

[Jeff Zemerick]

Apologies if this has been discussed previously. I've not kept up on the
Mi/NiFi progress as much lately.

When I think of two projects being combined I usually consider the
connection between the lifecycles of the two projects. One thing I always
liked about MiNiFi being separate was its ability to evolve outside the
NiFi lifecycle. New features, enhancements, and fixes could be released as
needed. It also had its own voting process for releases. But it certainly
had its drawbacks, too.

With the two projects being combined, is there any fear of negative effects
to MiNiFi's development being tied to NiFi's release cadence? Will it be
possible to do a MiNiFi release outside of a NiFi release? Or any desire to?

I'm not at all proposing not to merge the projects because there's a lot to
gain as stated in the initial email, but I would like to see MiNiFi be able
to maintain some of that independence and flexibility, if possible.

Thanks,
Jeff

On Thu, May 21, 2020 at 1:54 PM Joe Witt  wrote:

> Yes please!
>
> On Thu, May 21, 2020 at 1:53 PM Andy LoPresto 
> wrote:
>
> > Matt,
> >
> > I think this is a great idea, and I think it could also provide a bridge
> > to the reduced kernel build of NiFi with separate extensions that the
> > extensions registry will ultimately offer. Once the MiNiFi and NiFi
> > assemblies are complete, it should be possible to add a third which does
> > include the UI/API, but does not include the majority of specialized
> > processor NARs, etc.
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > He/Him
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On May 21, 2020, at 10:49 AM, Pierre Villard <
> > pierre.villard...@gmail.com> wrote:
> > >
> > > Nothing useful to add other than I know this is going to be a lot of
> > work,
> > > but this is GREAT!
> > >
> > > Thanks,
> > > Pierre
> > >
> > > Le jeu. 21 mai 2020 à 19:44, Matt Burgess  a
> > écrit :
> > >
> > >> All,
> > >>
> > >> I'm currently working on MINIFI-422, which aims to bring the MiNiFi
> > >> code into the NiFi codebase and have the MiNiFi product be a
> > >> specialized assembly of NiFi. Picture two different Maven profiles
> > >> that create a NiFi assembly or a MiNiFi assembly, each including the
> > >> common elements but excluding those things that aren't needed, such as
> > >> MiNiFi being "headless" and not including Jetty or the UI.
> > >>
> > >> This will be a lot of effort and very invasive to NiFi itself, so I
> > >> created a MINIFI-422 branch (based on the current master) and pushed
> > >> that to the Apache NiFi Github repo. I figure that way we can carve
> > >> out individual tasks and write PRs against that branch, rather than
> > >> duplicating code in the meantime and having MiNiFi show up little by
> > >> little in the NiFi codebase.
> > >>
> > >> My first task to that end is to continue Aldrin's work on MINIFI-488.
> > >> I originally had a PR against master for this subtask, but after
> > >> discussing with Aldrin we thought it would be better to have a
> > >> separate branch and incrementally add MiNiFi functionality until we're
> > >> ready for a big PR to bring it all into NiFi.
> > >>
> > >> We still want to keep up with NiFi master, so the branch would be
> > >> subject to force-pushes, rebases, etc. For that reason I'd like to ask
> > >> that anyone working on that branch please reach out to me
> > >> (mattyb...@apache.org) so we can coordinate and collaborate, to
> ensure
> > >> we're not stepping on each other's toes :)
> > >>
> > >> Also happy to discuss alternate approaches or any other questions or
> > >> concerns you may have.
> > >>
> > >> Regards,
> > >> Matt
> > >>
> >
> >
>

Re: [VOTE] Release Apache NiFi 1.10.0 (rc3)

[Jeff Zemerick]

+1 (non-binding)

Built and ran successfully and built custom processor with 1.10.0
dependency and successfully uploaded NAR to NiFi Registry 0.5.0.

On Wed, Oct 30, 2019 at 4:06 PM Mark Payne  wrote:

> +1 (binding)
>
> Was able to build and verify that all of the Jiras that I raised last time
> around have been addressed in this RC. Left a cluster of 10 nodes running
> for a day or two, pretty heavily taxed, and ran into no issues.
>
> Thanks
> -Mark
>
>
> > On Oct 30, 2019, at 3:20 PM, Matt Gilman 
> wrote:
> >
> > +1 (binding)
> >
> > Verified signatures, hashes, build, etc. Tested both standalone and
> > clustered and secure and unsecured.
> >
> > Thanks for RMing Joe!
> >
> > Matt
> >
> > On Wed, Oct 30, 2019 at 1:51 PM Adam Taft  wrote:
> >
> >> +1 (binding)
> >>
> >> Signatures verified.
> >> Hashes verified.
> >> Tests pass, source builds cleanly.
> >> I used both Java 11 & Java 8 to build.
> >>
> >> I did run into a problem compiling with Java 11 and running with Java
> 8.  I
> >> don't believe this was a goal of the Java 11 compatibility changes, so
> >> nothing unexpected about this. But it's possibly worth discussion in
> >> another thread (which I'll send out).  The convenience binary was
> compiled
> >> with Java 8, so no problems with compatibility either way.
> >>
> >> On Tue, Oct 29, 2019 at 11:32 AM Joe Witt  wrote:
> >>
> >>> Hello,
> >>>
> >>> I am pleased to be calling this vote for the source release of Apache
> >> NiFi
> >>> nifi-1.10.0.
> >>>
> >>> As they say 'third time's a charm'.
> >>>
> >>> The source zip, including signatures, digests, etc. can be found at:
> >>> https://repository.apache.org/content/repositories/orgapachenifi-1151
> >>>
> >>> The source being voted upon and the convenience binaries can be found
> at:
> >>> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.10.0/
> >>>
> >>> The Git tag is nifi-1.10.0-RC3
> >>> The Git commit ID is b217ae20ad6a04cac874b2b00d93b7f7514c0b88
> >>>
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=b217ae20ad6a04cac874b2b00d93b7f7514c0b88
> >>>
> >>> Checksums of nifi-1.10.0-source-release.zip:
> >>> SHA256:
> e9b0a14b3029acd69c6693781b6b6487c14dda12676db8b4a015bce23b1029c1
> >>> SHA512:
> >>>
> >>>
> >>
> b07258cbc21d2e529a1aa3098449917e2d059e6b45ffcfcb6df094931cf16caa8970576555164d3f2290cfe064b5780ba1a8bf63dad04d20100ed559a1cfe133
> >>>
> >>> Release artifacts are signed with the following key:
> >>> https://people.apache.org/keys/committer/joewitt.asc
> >>>
> >>> KEYS file available here:
> >>> https://dist.apache.org/repos/dist/release/nifi/KEYS
> >>>
> >>> 384 issues were closed/resolved for this release:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12344993
> >>>
> >>> Release note highlights can be found here:
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.10.0
> >>>
> >>> The vote will be open for 72 hours.
> >>> Please download the release candidate and evaluate the necessary items
> >>> including checking hashes, signatures, build
> >>> from source, and test. Then please vote:
> >>>
> >>> [ ] +1 Release this package as nifi-1.10.0
> >>> [ ] +0 no opinion
> >>> [ ] -1 Do not release this package because...
> >>>
> >>
>
>

Re: [VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Jeff Zemerick]

+1 non-binding

Built and ran MiNiFi and C2 without issues.

On Thu, Jun 28, 2018 at 3:59 PM Aldrin Piri  wrote:

> +1, binding
>
> comments:
> My vote is on the assumption there there was a slight mix up with tagging
> and it can be easily remedied.  The
> 05f516d3da33a0547ccfad342414504cdacd4a68
> points to the last commit and a snapshot version.  This is correct from
> where the release is started but does not capture the generated prepared
> release artifacts.  I believe if that is pushed and referenced, we will
> have what is packed in the source distribution, which is listed as 0.5.0,
> non-snapshot.
>
> signature and hashes looked good
> verified contrib, build, and tests of minifi, config-toolkit, and c2 server
> verified transform functionality of config toolkit
> verified consumption of transformed config in minifi and its successful
> site to site transaction to nifi
> verified interaction with c2 server with a file based provider
>
> On Thu, Jun 28, 2018 at 1:19 PM Jeremy Dyer  wrote:
>
> > Hello,
> >
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi
> > minifi-0.5.0 RC2.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > *https://repository.apache.org/content/repositories/orgapachenifi-1130/
> >  >*
> >
> > The Git tag is minifi-0.5.0-RC2
> > The Git commit ID is 05f516d3da33a0547ccfad342414504cdacd4a68
> > *
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=05f516d3da33a0547ccfad342414504cdacd4a68
> > <
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=05f516d3da33a0547ccfad342414504cdacd4a68
> > >*
> > *
> >
> https://github.com/apache/nifi-minifi/commit/05f516d3da33a0547ccfad342414504cdacd4a68
> > <
> >
> https://github.com/apache/nifi-minifi/commit/05f516d3da33a0547ccfad342414504cdacd4a68
> > >*
> >
> > wget
> >
> >
> https://repository.apache.org/content/repositories/orgapachenifi-1130/org/apache/nifi/minifi/minifi/0.5.0/minifi-0.5.0-source-release.zip
> >
> > Checksums of minifi-0.5.0-source-release.zip:
> > SHA1: be624db030aedd5c249e58c4c57d55ca917cd6ea
> > SHA256: 1f96ca7d8c2f52f9c15dad532065163f14cb01a2edbc783d4faa33656ff5ab88
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/jeremydyer.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 16 issues were closed/resolved for this release:
> > *
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921&version=12342658
> > <
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921&version=12342658
> > >*
> >
> > Release note highlights can be found here:
> > https://cwiki.apache.org/confluence/display/MINIFI/Release+
> > Notes#ReleaseNotes-Version0.5.0
> >
> > The vote will be open until 2:00PM EDT, 1 July 2018.
> >
> > Please download the release candidate and evaluate the necessary items
> > including checking hashes, signatures, build
> > from source, and test.  Then please vote:
> >
> > [ ] +1 Release this package as minifi-0.4.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> > Thanks!
> >
>

Re: [DISCUSS] Tar + Gzip vs. Zip

[Jeff Zemerick]

As a user I always download the zip file. Echoing Mike's reply, I work
across Linux, Windows, and OSX and my mouse always goes toward the zip.
I've never run into any file permission/attribute issues with the zip
distribution. Everything that should be executable always has been. So if
you axed one, my non-binding, FWIW vote would be to keep zip. :)

Jeff


On Tue, Jun 26, 2018 at 5:28 AM Mike Thomsen  wrote:

> I would lean toward Zip because it is the format that is supported by
> Windows, macOS and Linux out of the box. I think the ease of use for
> Windows users is particularly important.
>
> On Mon, Jun 25, 2018 at 11:34 PM Andy LoPresto 
> wrote:
>
> > Hi folks,
> >
> > I do not want to start a long-running argument or entrenched battle.
> > However, having just performed the RM duties for the latest release, I
> > believe I have identified a resource inefficiency in the fact that we
> > generate, upload, host, and distribute two compressed archives of the
> > binary which are functionally equivalent. For 1.7.0, both the .tar.gz and
> > .zip files are 1.2 GB (1_224_352_000 bytes for tar.gz vs. 1_224_392_000
> > bytes for zip). The time to build and sign these is substantial, but the
> > true cost comes in uploading and hosting them. While the fabled extension
> > registry will save all of us from this burden, it isn’t arriving
> tomorrow,
> > and I think we could drastically improve this before the next release.
> >
> > I have no personal preference between the two formats. In earlier days,
> > there were platform inconsistencies and the tools weren’t available on
> all
> > systems, but now they are pretty standard for all users. This [1] is an
> > interesting article I found which had some good info on the origins, and
> > here are some additional resources for anyone interested [2][3]. I don’t
> > care which we pick, but I propose removing one of the options for the
> build
> > going forward (toolkit as well).
> >
> > That said, if someone has a good reason that both are necessary, I would
> > love to hear it. I didn’t find anything on the Apache Release Policy
> which
> > stated we must offer both, but maybe I missed it. Thanks.
> >
> > [1] https://itsfoss.com/tar-vs-zip-vs-gz/
> > [2] https://superuser.com/a/1257441/40003
> > [3] https://superuser.com/a/173995/40003
> > [4] https://www.apache.org/legal/release-policy.html#artifacts
> >
> >
> > Andy LoPresto
> > alopre...@apache.org
> > *alopresto.apa...@gmail.com *
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> >
>

Re: [VOTE] Release Apache NiFi 1.7.0

[Jeff Zemerick]

+1 non-binding

Went through the guide without any problems. Ran some simple flows with no
issues.

After the first build I did see a Maven-generated directory called
something like "${project.parent.directory}" in the source root. I deleted
the entire thing, unzipped the source release again, built, and the
directory didn't show back up. I blame it on something with my Maven build
because it hasn't shown up again but I wanted to mention it in case it pops
up for someone else.

Jeff


On Thu, Jun 21, 2018 at 9:42 AM Bryan Bende  wrote:

> +1 (binding)
>
> Verified everything in release helper and ran some test flows, thanks
> for RM'ing!
>
> On Thu, Jun 21, 2018 at 9:11 AM, Mark Payne  wrote:
> > +1 (binding).
> >
> > Thanks for volunteering to handle the RM duties this time around, Andy!
> >
> > Was able to verify the checksums, build with contrib-check, verify
> signature. Started app up and
> > perform some simple verifications that the app behaved as expected.
> Verified README is present
> > and in good shape, as well as LICENSE and NOTICE files.
> >
> > Thanks!
> > -Mark
> >
> >
> >
> > On Jun 20, 2018, at 3:16 AM, Andy LoPresto  alopre...@apache.org>> wrote:
> >
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> NiFi nifi-1.7.0.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1127
> >
> > and
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.7.0
> >
> > The Git tag is nifi-1.7.0-RC1
> > The Git commit ID is 99bcd1f88dc826f857ae4ab33e842110bfc6ce21
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=99bcd1f88dc826f857ae4ab33e842110bfc6ce21
> >
> > Checksums of nifi-1.7.0-source-release.zip:
> > SHA1: 11086ef532bb51462d7e1ac818f6308d4ac62f03
> > SHA256: b616f985d486af3d05c04e375f952a4a5678f486017a2211657d5ba03aaaf563
> > SHA512:
> d81e9c6eb7fc51905d6f6629b25151fc3d8af7a3cd7cbc3aa03be390c0561858d614b62d8379a90fdb736fcf5c1b4832f4e050fdcfcd786e9615a0b5cc1d563d
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/alopresto.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 194 issues were closed/resolved for this release:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342979&projectId=12316020
> >
> > Release note highlights can be found here:
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.7.0
> >
> > The vote will be open for 72 hours.
> > Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> > from source, and test. Then please vote:
> >
> > [ ] +1 Release this package as nifi-1.7.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because…
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> >
>

Re: [VOTE] Release Apache NiFi Registry 0.2.0

[Jeff Zemerick]

+1 non-binding

Ran through the release helper guide with no issues. Good stuff!

On Sat, Jun 16, 2018 at 5:47 PM Andy LoPresto 
wrote:

> Sorry everyone,
>
> Committers can provide binding votes on technical discussions (such as to
> call for a release), but only PMC members can provide binding votes on
> releases. This is an Apache policy.
>
> I’ll update the page on Monday to be a bit clearer on the distinction.
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Jun 16, 2018, at 14:34, Andy LoPresto 
> wrote:
> >
> > Abdelkrim,
> >
> > Thanks for validating the release and voting. Just to clarify, only PMC
> members and committers [1] can cast a “binding” vote. All other community
> members are welcome to cast a +1, 0, or -1 vote as well, but these are
> “non-binding”. Thanks again.
> >
> > [1] http://nifi.apache.org/people.html
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> >> On Jun 16, 2018, at 14:23, Abdelkrim Hadjidj 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> - Tested everything from the release helper and everything worked fine
> >> - Tested the GitFlowPersistenceProvider with Github, works fine
> >> - The Switching from other Persistence Provider section of the Admin
> Guide asks to move the H2 DB specified as nifi.registry.db.directory. In
> the Registery 0.2, this property is set to "". So it doesn't apply when you
> start a Registry 0.2 with FilePersistenceProvider and migrate to Git
> provider.
> >> - This is not an issue, but it seems that there no way to migrate
> previous flow file from File provider to Git provider, or from an existing
> Git provider with Git clone.
> >>
> >> Thanks
> >>
> >> On 6/16/18, 3:22 PM, "Bryan Bende"  wrote:
> >>
> >>+1 (binding) Release this package as nifi-registry-0.2.0
> >>
> >>- Ran through everything in the release helper and looked good, few
> minor
> >>things Andy mentioned
> >>- Tested upgrading an existing registry to 0.2.0 to test database
> migration
> >>- Tested basic event hook logging
> >>- Ran secure NiFi with secure registry
> >>
> >>I also never saw the strange Maven output that Andy reported.
> >>
> >>Thanks for RM'ing!!
> >>
> >>
> >>>On Sat, Jun 16, 2018 at 1:29 AM, Andy LoPresto <
> alopre...@apache.org> wrote:
> >>>
> >>> +1, binding
> >>>
> >>> I:
> >>> * verified all checksums and signatures
> >>> * ran through the normal build process (tests and contrib-check)
> >>> * verified the LICENSE, NOTICE, and README.md documents
> >>> * deployed the application
> >>> * verified interaction with NiFi
> >>>
> >>> I also deployed a secured NiFi Registry and NiFi instance and was able
> to
> >>> perform expected behavior. I then encrypted the Registry configs and
> >>> verified the application still worked.
> >>>
> >>> There were a lot of tiny issues, but none that I believe raise to the
> >>> level of blocking the release. I’ve included brief notes here but will
> open
> >>> Jiras for these at a later date. Thanks Kevin, great work.
> >>>
> >>> * Maven build has weird output at the end (see below; seems like text
> >>> interpolation from race condition? may only be my machine, but I ran
> >>> single-threaded)
> >>> * source NOTICE includes copyright date 2014-2018 (who has the
> DeLorean?)
> >>> * source NOTICE says MiNiFi copyright date 2015-2018?
> >>> * Probably should have spaces around hyphens in "Registry-a
> sub-project of
> >>> Apache NiFi-is" in source README.md
> >>> * compiled NOTICE includes copyright date 2014-2018
> >>> * compiled NOTICE says NiFi copyright 2015-2017
> >>> * compiled README does not have markdown extension
> >>> * compiled README does not have complete instructions from source
> README.md
> >>> * git commit to prepare for release has formatting changes (try to
> avoid)
> >>>
> >>> ——
> >>> [INFO] ---< org.apache.nifi.registry:nifi-registry-docker
>  
> >>> [INFO] Building nifi-registry-docker 0.2.0
> >>> [20/20]
> >>> [INFO] [ jar
> >>> ]-
> >>> [INFO]
> >>> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
> >>> nifi-registry-docker ---
> >>> [INFO]
> >>> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven) @
> >>> nifi-registry-docker ---
> >>> [INFO]
> >>> [INFO] --- maven-remote-resources-plugin:1.5:process (default) @
> >>> nifi-registry-docker ---
> >>> [INFO]
> >>> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> >>> nifi-registry-docker ---
> >>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> >>> [INFO] skip non existing resourceDirectory /Users/alopresto/Workspace/
> >>> scratch/release_verification/registry-0.2.0/nifi-registry-
> >>> 0.2.0/nifi-registry-docker/src/main/resources
> >>> [INFO] Copying 3 resources
> >>> [INFO]
> >>

Re: Dependency versions in processors in 1.6.0

[Jeff Zemerick]

Bryan, thanks for confirming!

Yes, they were gson, commons-io, and nifi-mock. (It's a pretty simple
processor with not many dependencies.)

Thanks,
Jeff


On Tue, May 29, 2018 at 9:19 AM Bryan Bende  wrote:

> Jeff,
>
> What you described sounds correct. Can you share which dependency
> versions now need to be specified? We could at least update the
> processor bundle archetype to have these versions specified to make it
> easier for new bundles, and maybe add something to the migration notes
> for existing bundles.
>
> Thanks,
>
> Bryan
>
>
> On Tue, May 29, 2018 at 7:29 AM, Jeff Zemerick 
> wrote:
> > Hi,
> >
> > In <=1.5.0 processors I used nifi-nar-bundles as the parent project and
> > dependency management was handled for me. Changing to 1.6.0 resulted in a
> > few "missing dependency version" errors. I think this is expected due
> > to NIFI-4936 ("NiFi parent pom dependency management forcing versions to
> > align defeating classloader isolation") but I wanted to make sure that me
> > adding versions for those dependencies is the correct thing to do.
> >
> > Thanks,
> > Jeff
>

Dependency versions in processors in 1.6.0

[Jeff Zemerick]

Hi,

In <=1.5.0 processors I used nifi-nar-bundles as the parent project and
dependency management was handled for me. Changing to 1.6.0 resulted in a
few "missing dependency version" errors. I think this is expected due
to NIFI-4936 ("NiFi parent pom dependency management forcing versions to
align defeating classloader isolation") but I wanted to make sure that me
adding versions for those dependencies is the correct thing to do.

Thanks,
Jeff

Re: MiNiFi PeriodicStatusReporter and AWS CloudWatch

[Jeff Zemerick]

Thanks! I will take a look at those.

Jeff

On Wed, May 23, 2018 at 9:20 AM Aldrin Piri  wrote:

> Hey Jeff,

> I don't think there is anything that maps directly to the functionality
you
> are trying to cover.  From a broader, ecosystem standpoint there is a
> Processor in NiFi that transmits data to Cloudwatch as part of the AWS
> NAR.  It might be helpful to explore what functionality is there
especially
> with auth scenarios as I do remember scoping out a few PRs related to such
> matters.

> In terms of execution, I might be more inclined to opt for a reporting
> task.   I think the status reporter's original scope was more of a "local"
> and interactive experience with the instance.  For this kind of regular,
> hands off approach, you could get the same type of information in the
> format specifically needed via the context exposed to the reporting task.

> --aldrin

> On Wed, May 23, 2018 at 8:41 AM, Jeff Zemerick 
wrote:

> > Hi everyone,
> >
> > I'm looking for ways to monitor a distributed fleet of MiNiFi (Java)
> > installations. I'd like essentially a dashboard that shows the overall
> > health of the installations. I can leverage AWS CloudWatch for the
> > dashboard capability with the added benefit of CloudWatch alarms. The
> > PeriodicStatusReporter looks like a good way to implement it. Before I
give
> > it a go, I just wanted to make sure I'm not reinventing the wheel
anywhere
> > and that the community might find this useful instead of just me or if
> > there are any gotchas that I might be missing.
> >
> > Thanks!
> > Jeff
> >

MiNiFi PeriodicStatusReporter and AWS CloudWatch

[Jeff Zemerick]

Hi everyone,

I'm looking for ways to monitor a distributed fleet of MiNiFi (Java)
installations. I'd like essentially a dashboard that shows the overall
health of the installations. I can leverage AWS CloudWatch for the
dashboard capability with the added benefit of CloudWatch alarms. The
PeriodicStatusReporter looks like a good way to implement it. Before I give
it a go, I just wanted to make sure I'm not reinventing the wheel anywhere
and that the community might find this useful instead of just me or if
there are any gotchas that I might be missing.

Thanks!
Jeff

Re: Read processor property in init()

[Jeff Zemerick]

Thanks! Just to confirm, each time the processor is started the
@OnScheduled annotated method is executed, right?

Jeff


On Wed, Mar 28, 2018 at 9:07 AM, Sivaprasanna 
wrote:

> Just to add on top of what Mike said. The @OnScheduled annotation indicates
> that the method that is marked with this annotation will run when a
> processor is started every time. So basically the setup() will be called
> and executed everytime the processor is started from the UI.
>
> On Wed, 28 Mar 2018 at 6:34 PM, Jeff Zemerick 
> wrote:
>
> > I will give that a go. Thanks for the quick answer, Mike!
> >
> > On Wed, Mar 28, 2018 at 9:01 AM, Mike Thomsen 
> > wrote:
> > > Just do...
> > >
> > > @OnScheduled
> > > public void setup(ProcessContext context) {
> > >     //Read properties and do setup.
> > > }
> > >
> > > On Wed, Mar 28, 2018 at 8:57 AM, Jeff Zemerick 
> > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> Is there a recommended method for making user-configurable property
> > >> values available to a processor's init()? I would like to load a large
> > >> index file but allow the user to specify the index's path. I am
> > >> guessing that init() is executed too early to read user properties.
> > >>
> > >> Thanks for any suggestions.
> > >>
> > >> Jeff
> > >>
> >
>

Re: Read processor property in init()

[Jeff Zemerick]

I will give that a go. Thanks for the quick answer, Mike!

On Wed, Mar 28, 2018 at 9:01 AM, Mike Thomsen  wrote:
> Just do...
>
> @OnScheduled
> public void setup(ProcessContext context) {
> //Read properties and do setup.
> }
>
> On Wed, Mar 28, 2018 at 8:57 AM, Jeff Zemerick  wrote:
>
>> Hi everyone,
>>
>> Is there a recommended method for making user-configurable property
>> values available to a processor's init()? I would like to load a large
>> index file but allow the user to specify the index's path. I am
>> guessing that init() is executed too early to read user properties.
>>
>> Thanks for any suggestions.
>>
>> Jeff
>>

Read processor property in init()

[Jeff Zemerick]

Hi everyone,

Is there a recommended method for making user-configurable property
values available to a processor's init()? I would like to load a large
index file but allow the user to specify the index's path. I am
guessing that init() is executed too early to read user properties.

Thanks for any suggestions.

Jeff

Re: [VOTE] Release Apache NiFi 1.6.0 (RC2)

[Jeff Zemerick]

+1 non-binding

Built successfully and tests pass.
Ran some simple flows -- worked as expected.

On Tue, Mar 27, 2018 at 9:59 AM, Matt Burgess  wrote:
> +1 (binding) Release this package as nifi-1.6.0
>
> Verified checksums, commit, L&N, etc. Ran full build with unit tests
> and tried various flows, all looks well!
>
>
> On Mon, Mar 26, 2018 at 11:34 PM, Joe Witt  wrote:
>> Hello,
>>
>> I am pleased to be calling this vote for the source release of Apache
>> NiFi nifi-1.6.0.
>>
>> The source zip, including signatures, digests, etc. can be found at:
>> https://repository.apache.org/content/repositories/orgapachenifi-1123
>>
>> The Git tag is nifi-1.6.0-RC2
>> The Git commit ID is b5935ec81a7cbc048820781ac62cd96bbea5b232
>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=b5935ec81a7cbc048820781ac62cd96bbea5b232
>>
>> Checksums of nifi-1.6.0-source-release.zip:
>> SHA1: 009f1e2e3c17e38f21f27170b9c06228d11653c0
>> SHA256: 39941a5b25427e2b4cc5ba8206084ff92df58863f29ddd097d4ac1e85424beb9
>> SHA512: 
>> 1773417a48665e3cda22180ea7f401bc8190ebddbf3f7bc29831e46e7ab0a07694c6e478d252fa573209d4a3c8132a522a8507b6a8784669ab7364847a07e234
>>
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/joewitt.asc
>>
>> KEYS file available here:
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>
>> 146 issues were closed/resolved for this release:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12342422
>>
>> Release note highlights can be found here:
>> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.6.0
>>
>> The vote will be open for 72 hours.
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build
>> from source, and test.  The please vote:
>>
>> [ ] +1 Release this package as nifi-1.6.0
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...

Re: [DISCUSS] MiNiFi Flow Designer

[Jeff Zemerick]

I think it sounds like a good idea. The majority of the MiNiFi flows I have
made are all fairly simple and I have not found the YAML authoring to be
overly burdensome. The more complex flows were done in NiFi and converted.
So as long as the option to make the flows by hand remains (and I don't
think there was anything in the proposal to the contrary), I think it would
be a beneficial addition.

Jeff


On Thu, Mar 1, 2018 at 2:21 PM, Scott Aslan  wrote:

> AndyC/Aldrin,
>
> The UI/UX design system sub project currently under discussion will be
> based off of the work completed during the NiFi Registry and will not
> contain any UI/UX functionality from NiFi. The long term goal would be to
> upgrade angular in the NiFi UI in order to leverage this new design system.
>
> -Scotty
>
>
> On Thu, Mar 1, 2018 at 1:45 PM, Kevin Doran  wrote:
>
> > Aldrin,
> >
> > Thanks a lot for taking the time to write up such a detailed and well
> > thought out proposal.
> >
> > I really like the idea of publishing flows to NiFi Registry that then get
> > deployed to MiNiFi agents via the C2 Server. I don't have much to add
> > there, and I think that you've identified one of the big missing parts to
> > make that experience user-friendly -- how to design and author the flows
> in
> > the first place.
> >
> > The MiNiFi Flow Designer would fill that need in a really elegant way
> with
> > a low learning curve for NiFi users. Having the ability to design and
> > author flows in an environment other than the "runtime" environment one
> is
> > targeting would be a huge step forward. Not just for MiNiFi, but
> > multi-environment deployments of NiFi, where one might be developing a
> flow
> > in an environment other than where they intend to run it. This would make
> > the SDLC options for NiFi flows even more flexible, which is a big part
> of
> > the goal of the new NiFi Registry.
> >
> > It certainly presents some challenges, but I definitely think the upside
> > for MiNiFi flow authoring would be huge.
> >
> > Thanks,
> > Kevin
> >
> > On 2/28/18, 07:53, "Aldrin Piri"  wrote:
> >
> > It appears I accidentally left off the actual links.  Here they are
> in
> > all
> > their glory:
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/MINIFI/
> > MiNiFi+Command+and+Control
> > [2]
> > https://github.com/apache/nifi-minifi/blob/master/
> > minifi-docs/src/main/markdown/System_Admin_Guide.md#config-file
> > [3] https://issues.apache.org/jira/browse/MINIFICPP-36
> > [4] https://github.com/apache/nifi-minifi/tree/master/minifi-c2
> > [5]
> > https://github.com/apache/nifi-minifi/tree/master/
> > minifi-c2#configuration-providers
> > [6]
> > https://github.com/apache/nifi-minifi/blob/master/
> > minifi-docs/src/main/markdown/System_Admin_Guide.md#
> > automatic-warm-redeploy
> > [7]
> > https://cwiki.apache.org/confluence/display/NIFI/
> > Extension+Repositories+%28aka+Extension+Registry%29+for+
> > Dynamically-loaded+Extensions
> > [8]
> > https://cwiki.apache.org/confluence/display/MINIFI/
> > MiNiFi+Command+and+Control#MiNiFiCommandandControl-FlowAuthorshipDetails
> >
> >
> > On Wed, Feb 28, 2018 at 1:53 AM, Aldrin Piri 
> > wrote:
> >
> > > Hey folks,
> > >
> > > With the release of Registry, I’ve been contemplating leveraging it
> > and
> > > the current codebase of NiFi to facilitate ease of use for MiNiFi
> > flow
> > > design.  One of the areas I would like to form a concerted effort
> > around is
> > > that of the Command and Control (C2) functionality originally
> > presented
> > > when the MiNiFi effort was started and further expounded upon with
> a
> > > feature proposal [1].  In that proposal, while the names are dated,
> > we have
> > > components that fulfill some of the core building blocks toward the
> > overall
> > > vision of C2.
> > >
> > > For those not intimately familiar, MiNiFi is primarily configured
> > via a
> > > YAML configuration file.  [2]  The initial idea was that flows
> would
> > be
> > > simple a source, maybe a transform or two, and then transmission.
> > The
> > > notion was that hand creation of one of these files would not be
> > overly
> > > onerous.  It became apparent from questions, however, that users
> > were doing
> > > more complex flows and this YAML ranged from tedious to difficult
> > for those
> > > situations.  This precipitated the best approach currently
> available,
> > > utilizing a NiFi instance as a way to generate a template.  This
> > template
> > > was then exported, and using our provided toolkit to get YAML out
> > that is
> > > deployable with your instance.  Better, but far from ideal.
> > >
> > > A couple approaches came to mind to further narrow this gap of user
> > > expectation and realities of our configuration.
> > >
> > > (1) In our current state, we have heavily relied on convenience o

Re: [VOTE] Release Apache NiFi MiNiFi 0.4.0 RC2

[Jeff Zemerick]

+1 non-binding

Built and ran fine.
As mentioned in hipchat I didn't see the git tag nifi-minifi-0.4.0-RC2 but
verified the commit.

On Sat, Jan 20, 2018 at 3:00 PM, Ben Qiu  wrote:

> +1
>
> On 2018-01-18 12:55, Aldrin Piri  wrote:
> > Hello,>
> >
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi nifi-minifi-0.4.0.>
> >
> > The source zip, including signatures, digests, etc. can be found at:>
> > https://repository.apache.org/content/repositories/orgapachenifi-1119>
> >
> > The Git tag is nifi-minifi-0.4.0-RC2>
> > The Git commit ID is 5e19068e2d35dd9b5d5f45e75efb0414d84d226b>
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> 5e19068e2d35dd9b5d5f45e75efb0414d84d226b>
>
> >
> https://github.com/apache/nifi-minifi/commit/
> 5e19068e2d35dd9b5d5f45e75efb0414d84d226b>
>
> >
> > Checksums of nifi-minifi-0.4.0-source-release.zip:>
> > MD5: 237bb2f3fe26ff6451273c3c39579bf6>
> > SHA1: 2d53dd08b55a2799da97008bf971657546c0a752>
> > SHA256: b0ee425f7c214d423f22b75aa2006dcdabf407cd29b0bd2c4f8a8ea3a3ec
> 4b18>
> >
> > Release artifacts are signed with the following key:>
> > https://people.apache.org/keys/committer/aldrin.asc>
> >
> > KEYS file available here:>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS>
> >
> > 5 issues were closed/resolved for this release:>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12319921&version=12342439>
>
> >
> > Release note highlights can be found here:>
> > https://cwiki.apache.org/confluence/display/MINIFI/Release
> Notes#ReleaseNotes-Version0.4.0>
> >
> > The vote will be open until 4:00PM EST, 22 January 2018 [1].>
> >
> > Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build>
> > from source, and test.  Then please vote:>
> >
> > [ ]  1 Release this package as minifi-0.4.0>
> > [ ]  0 no opinion>
> > [ ] -1 Do not release this package because...>
> >
> > Thanks!>
> >
> > [1] You can determine this time for your local time zone at
> https://s.apache.org/minifi-0.4.0-rc2-close>
> >
>

Re: [VOTE] Release Apache NiFi MiNiFi 0.4.0

[Jeff Zemerick]

Verified keys, hashes, and built fine with contrib-check.

However it fails to start. (I did not modify the config prior to starting.)
>From the log:

2018-01-18 11:31:40,743 WARN [main] org.apache.nifi.minifi.MiNiFiServer
Failed to start minifi server... shutting down.
java.lang.Exception: Unable to load flow due to:
java.lang.NullPointerException
at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:133)
at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:148)
at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:247)
Caused by: java.lang.NullPointerException: null
at
org.apache.nifi.controller.serialization.StandardFlowSerializer.addFlowRegistries(StandardFlowSerializer.java:141)
at
org.apache.nifi.controller.serialization.StandardFlowSerializer.serialize(StandardFlowSerializer.java:107)
at
org.apache.nifi.controller.FlowController.serialize(FlowController.java:1590)
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.save(StandardXMLFlowConfigurationDAO.java:141)
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.save(StandardXMLFlowConfigurationDAO.java:132)
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:94)
at
org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:723)
at
org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:534)
at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:121)
... 2 common frames omitted

I'm using the downloaded source release and built in a new directory so
shouldn't be any modified files in there. Wondering if the default config
needs modified..?

Thanks,
Jeff



On Wed, Jan 17, 2018 at 9:33 AM, Aldrin Piri  wrote:

> Hello,
>
> I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi minifi-0.4.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1118
>
> The Git tag is nifi-minifi-0.4.0-RC1
> The Git commit ID is 0bbb4323a9cb42e4510bde0f58b4950eea1582df
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> 0bbb4323a9cb42e4510bde0f58b4950eea1582df
> https://github.com/apache/nifi-minifi/commit/
> 0bbb4323a9cb42e4510bde0f58b4950eea1582df
>
> Checksums of minifi-0.4.0-source-release.zip:
> MD5: f8a32ec73e8b52cc9496165b87abd0ec
> SHA1: 7b0d60c11fc724f5bb5630391110b8861351c4e2
> SHA256: c566f437b37c1dd912c4577c4a3fa12e36780f71485854de6e92bc7ed40a5699
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/aldrin.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 3 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12319921&version=12342439
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Version0.4.0
>
> The vote will be open until 10:00AM EST, 20 January 2018 [1].
>
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  Then please vote:
>
> [ ] +1 Release this package as minifi-0.4.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Thanks!
>
> [1] You can determine this time for your local time zone at
> https://s.apache.org/minifi-0.4.0-rc1-close
>

Re: [VOTE] Release Apache NiFi 1.5.0 (RC1)

[Jeff Zemerick]

+1 non-binding

Built with contrib-check.
Stepped through release guide.

Ran into a minor issue with the TestListenSMTP unit tests on OSX but it
might be pretty specific to my computer.

https://issues.apache.org/jira/browse/NIFI-4760


On Wed, Jan 10, 2018 at 10:26 AM, Pierre Villard <
pierre.villard...@gmail.com> wrote:

> +1 (binding)
>
> Went through release helper guide and all looks good to me.
> Tested integration with a running registry instance.
> Ran some test workflows in a secured env and tested recent fixed about
> authorizers.
>
> Thanks for taking care of the release Joe!
> Great job from all the community around this release! Integration with the
> registry is neat.
>
> Pierre
>
>
>
> 2018-01-10 16:16 GMT+01:00 Bryan Bende :
>
> > +1 (binding)
> >
> > - Ran through release helper with no issues
> > - Ran into a minor issue related to component versioning when using
> > the registry and created this JIRA [1], would be more of an issue for
> > next release
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-4763
> >
> >
> > On Wed, Jan 10, 2018 at 10:05 AM, Matt Burgess 
> > wrote:
> > > +1 (binding), ran through release guide with no issues (verified sigs
> > > & sums), ran various flows using record processors, the new Jackson
> > > CSV parser, provenance reporting task with new filtering capability
> > > and output fields, etc.
> > >
> > > On Tue, Jan 9, 2018 at 5:19 AM, Joe Witt  wrote:
> > >> Hello,
> > >>
> > >> I am pleased to be calling this vote for the source release of Apache
> > >> NiFi nifi-1.5.0.
> > >>
> > >> The source zip, including signatures, digests, etc. can be found at:
> > >> https://repository.apache.org/content/repositories/orgapachenifi-1116
> > >>
> > >> The Git tag is nifi-1.5.0-RC1
> > >> The Git commit ID is 46d30c7e92f0ad034d9b35bf1d05c350ab5547ed
> > >> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> > 46d30c7e92f0ad034d9b35bf1d05c350ab5547ed
> > >>
> > >> Checksums of nifi-1.5.0-source-release.zip:
> > >> MD5: 046f2dde4af592dd8c05e55c2bbb3c4f
> > >> SHA1: 63b9a68b9f89200fd31f5561956a15b45b1b9c8c
> > >> SHA256: 40b155c4911414907835f2eb0d5a4da798935f27f1e5134218d904fe6c94
> > 2d13
> > >>
> > >> Release artifacts are signed with the following key:
> > >> https://people.apache.org/keys/committer/joewitt.asc
> > >>
> > >> KEYS file available here:
> > >> https://dist.apache.org/repos/dist/release/nifi/KEYS
> > >>
> > >> 195 issues were closed/resolved for this release:
> > >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12316020&version=12341668
> > >>
> > >> Release note highlights can be found here:
> > >> https://cwiki.apache.org/confluence/display/NIFI/
> > Release+Notes#ReleaseNotes-Version1.5.0
> > >>
> > >> The vote will be open for 72 hours.
> > >> Please download the release candidate and evaluate the necessary items
> > >> including checking hashes, signatures, build
> > >> from source, and test.  The please vote:
> > >>
> > >> [ ] +1 Release this package as nifi-1.5.0
> > >> [ ] +0 no opinion
> > >> [ ] -1 Do not release this package because...
> >
>

Re: Apache NiFi 1.5.0 (RC1) Release Helper Guide

[Jeff Zemerick]

Thanks, Joe! It was a parallel build. I will write it up in a ticket.

On Wed, Jan 10, 2018 at 1:48 AM, Joe Witt  wrote:

> Thanks for fixing that directory/link Aldrin!
>
> JeffZ: With regard to your ask on hipchat "Hi guys. Building 1.5.0 RC
> on OSX and I get a few failing tests in TestListenSMTP. The tests pass
> on Ubuntu. Just wondering if those are known failures? I didn't see
> any open JIRAs with a quick search."
>
> I responded with
>
> "[10:50 PM] Joe Witt: not known errors. Please share the build
> command you're using
> [10:51 PM] Joe Witt: Those tests have been problematic in the past
> because they started on a specific port and in parallel build cases
> the port might be in use. However, some changes were made to improve
> that. We probably need to just make them be integration tests only.
> Please do file a JIRA with your observations"
>
> Thanks
>
> On Tue, Jan 9, 2018 at 6:09 AM, Aldrin Piri  wrote:
> > Looks like there was an extra nifi directory created.  I moved them in
> the
> > repo to reflect the paths in the helper email.
> >
> >
> > On Tue, Jan 9, 2018 at 7:52 AM, Jeff Zemerick 
> wrote:
> >
> >> Hi Joe,
> >>
> >> I'm getting a 404 on those download links.
> >>
> >> Thanks
> >>
> >>
> >> On Tue, Jan 9, 2018 at 5:19 AM, Joe Witt  wrote:
> >>
> >> > Hello Apache NiFi community,
> >> >
> >> > Please find the associated guidance to help those interested in
> >> > validating/verifying the release so they can vote.
> >> >
> >> > # Download latest KEYS file:
> >> > https://dist.apache.org/repos/dist/dev/nifi/KEYS
> >> >
> >> > # Import keys file:
> >> > gpg --import KEYS
> >> >
> >> > # [optional] Clear out local maven artifact repository
> >> >
> >> > # Pull down nifi-1.5.0 source release artifacts for review:
> >> >
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> >> > 1.5.0-source-release.zip
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> >> > 1.5.0-source-release.zip.asc
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> >> > 1.5.0-source-release.zip.md5
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> >> > 1.5.0-source-release.zip.sha1
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> >> > 1.5.0-source-release.zip.sha256
> >> >
> >> > # Verify the signature
> >> > gpg --verify nifi-1.5.0-source-release.zip.asc
> >> >
> >> > # Verify the hashes (md5, sha1, sha256) match the source and what was
> >> > provided in the vote email thread
> >> > md5sum nifi-1.5.0-source-release.zip
> >> > sha1sum nifi-1.5.0-source-release.zip
> >> > sha256sum nifi-1.5.0-source-release.zip
> >> >
> >> > # Unzip nifi-1.5.0-source-release.zip
> >> >
> >> > # Verify the build works including release audit tool (RAT) checks
> >> > cd nifi-1.5.0
> >> > mvn clean install -Pcontrib-check,include-grpc
> >> >
> >> > # Verify the contents contain a good README, NOTICE, and LICENSE.
> >> >
> >> > # Verify the git commit ID is correct
> >> >
> >> > # Verify the RC was branched off the correct git commit ID
> >> >
> >> > # Look at the resulting convenience binary as found in
> >> nifi-assembly/target
> >> >
> >> > # Make sure the README, NOTICE, and LICENSE are present and correct
> >> >
> >> > # Run the resulting convenience binary and make sure it works as
> expected
> >> >
> >> > # Send a response to the vote thread indicating a +1, 0, -1 based on
> >> > your findings.
> >> >
> >> > Please note that the convenience binaries and artifacts are provided
> >> > except for the tar.gz/zip of the actual nifi build.
> >> > It is simply too large to upload at this time.  But once
> >> > https://issues.apache.org/jira/browse/INFRA-15816 is
> >> > addressed I will upload it.
> >> >
> >> > Thank you for your time and effort to validate the release!
> >> >
> >>
>

Re: Apache NiFi 1.5.0 (RC1) Release Helper Guide

[Jeff Zemerick]

Hi Joe,

I'm getting a 404 on those download links.

Thanks


On Tue, Jan 9, 2018 at 5:19 AM, Joe Witt  wrote:

> Hello Apache NiFi community,
>
> Please find the associated guidance to help those interested in
> validating/verifying the release so they can vote.
>
> # Download latest KEYS file:
> https://dist.apache.org/repos/dist/dev/nifi/KEYS
>
> # Import keys file:
> gpg --import KEYS
>
> # [optional] Clear out local maven artifact repository
>
> # Pull down nifi-1.5.0 source release artifacts for review:
>
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> 1.5.0-source-release.zip
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> 1.5.0-source-release.zip.asc
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> 1.5.0-source-release.zip.md5
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> 1.5.0-source-release.zip.sha1
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.5.0/nifi-
> 1.5.0-source-release.zip.sha256
>
> # Verify the signature
> gpg --verify nifi-1.5.0-source-release.zip.asc
>
> # Verify the hashes (md5, sha1, sha256) match the source and what was
> provided in the vote email thread
> md5sum nifi-1.5.0-source-release.zip
> sha1sum nifi-1.5.0-source-release.zip
> sha256sum nifi-1.5.0-source-release.zip
>
> # Unzip nifi-1.5.0-source-release.zip
>
> # Verify the build works including release audit tool (RAT) checks
> cd nifi-1.5.0
> mvn clean install -Pcontrib-check,include-grpc
>
> # Verify the contents contain a good README, NOTICE, and LICENSE.
>
> # Verify the git commit ID is correct
>
> # Verify the RC was branched off the correct git commit ID
>
> # Look at the resulting convenience binary as found in nifi-assembly/target
>
> # Make sure the README, NOTICE, and LICENSE are present and correct
>
> # Run the resulting convenience binary and make sure it works as expected
>
> # Send a response to the vote thread indicating a +1, 0, -1 based on
> your findings.
>
> Please note that the convenience binaries and artifacts are provided
> except for the tar.gz/zip of the actual nifi build.
> It is simply too large to upload at this time.  But once
> https://issues.apache.org/jira/browse/INFRA-15816 is
> addressed I will upload it.
>
> Thank you for your time and effort to validate the release!
>

Re: [VOTE] Release Apache NiFi MiNiFi 0.3.0 - RC3

[Jeff Zemerick]

+1 non-binding

verified hashes
verified signature
verified git commit
verified RC branch commit
successful build with contrib-check
verified the three sets of README, LICENSE, NOTICE files
verified windows service operation

Thanks for putting these RCs together!

Jeff


On Tue, Dec 19, 2017 at 12:51 AM, Koji Kawamura 
wrote:

> Thanks Aldrin for updating RC again, and to all devs who contributed
> to MiNiFi 0.3.0 release!
>
> I confirmed:
> - Hashes are correct
> - MiNiFi Windows Service works
> - MiNiFi Toolset works, NiFi template -> MiNiFi config yml
> - NiFi template -> C2 server -> MiNiFi PullHttpChangeIngestor works nicely
>
> +1 Release this package as minifi-0.3.0
>
> Koji
>
> On Tue, Dec 19, 2017 at 7:09 AM, Aldrin Piri  wrote:
> > Hello,
> >
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi,
> > minifi-0.3.0.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1114/
> >
> > The Git tag is minifi-0.3.0-RC3
> > The Git commit ID is f06a7190ac07dbf02e5b0f9ee2859dea08acf3b0
> > *
> > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> f06a7190ac07dbf02e5b0f9ee2859dea08acf3b0
> > *
> > https://github.com/apache/nifi-minifi/commit/
> f06a7190ac07dbf02e5b0f9ee2859dea08acf3b0
> >
> > Checksums of minifi-0.3.0-source-release.zip:
> > MD5: 685e890486dbde4fd75db86128adf140
> > SHA1: 9dcf7d1b440b1247ca0c55e2ffdc75574467fed6
> > SHA256: a1c9be5ca4824fe98620d7df68469c8b9ea9461fb8dbecd1bdd6596e0b5dea89
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/aldrin.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 23 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12319921&version=12340598
> >
> > Release note highlights can be found here:
> > https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Version0.3.0
> >
> > The vote will be open until 7:00PM EST, 21 December 2017 [1].
> >
> > Please download the release candidate and evaluate the necessary items
> > including checking hashes, signatures, build
> > from source, and test.  Then please vote:
> >
> > [ ] +1 Release this package as minifi-0.3.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> > Thanks!
> >
> > [1] You can determine this time for your local time zone at
> > https://s.apache.org/minifi-0.3.0-rc3-close
>

MiNiFi (Java) 0.3.0

[Jeff Zemerick]

I'm curious what the community thinks about a Java MiNiFi 0.3.0 release.
Looks like 18 tasks [1] have been closed in 0.3.0 and there are no open
pull requests. Is there anything outstanding that is waiting to be
addressed and should go into a 0.3.0?

Thanks,
Jeff

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921&version=12340598

MINIFI-403 and JsonParseException

[Jeff Zemerick]

Hi all,

While working on Java MiNiFi in the master branch I ran into a
NoClassDefFoundError for org.codehaus.jackson.JsonParseException (stack
trace at the bottom) when MiNiFi starts. Thinking I had not seen this
before I reverted MINIFI-403 since it dealt with dependencies, rebuilt, and
the exception goes away and MiNiFi starts and runs as expected. Resetting
to head and building and running again brings the exception back.

When running MiNiFi built with MINIFI-403 I see the Jackson jars on the
classpath in the log. (Looks like the jars I would expect. I don't know
which one specifically has JsonParseException but I'd think it would be in
one of them.)

So I am wondering if this expected and I need to do something else or if
this exception is unexpected and I should look into it more? If relevant,
my flow is the classic test flow to tail minifi-app.log to a local NiFi.

Thanks,
Jeff

java.lang.NoClassDefFoundError: org/codehaus/jackson/JsonParseException
at
org.apache.nifi.remote.StandardRemoteProcessGroup.getTargetUri(StandardRemoteProcessGroup.java:357)
at
org.apache.nifi.controller.serialization.StandardFlowSerializer.addRemoteProcessGroup(StandardFlowSerializer.java:271)
at
org.apache.nifi.controller.serialization.StandardFlowSerializer.addProcessGroup(StandardFlowSerializer.java:190)
at
org.apache.nifi.controller.serialization.StandardFlowSerializer.serialize(StandardFlowSerializer.java:96)
at
org.apache.nifi.controller.FlowController.serialize(FlowController.java:1512)
at
org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.save(StandardXMLFlowConfigurationDAO.java:163)
at
org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:535)
at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:113)
at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:140)
at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:239)
Caused by: java.lang.ClassNotFoundException:
org.codehaus.jackson.JsonParseException
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 10 common frames omitted

Re: Separate MiNiFi projects in JIRA

[Jeff Zemerick]

Great! Thanks!

On Tue, Sep 19, 2017 at 9:56 AM, Aldrin Piri  wrote:

> Hey folks,
>
> The new JIRA project is now live.  Please make use of that when filing C++
> related JIRAs.  I am going to start moving appropriate items to that
> instance.
>
> On Mon, Sep 4, 2017 at 2:13 PM, Aldrin Piri  wrote:
>
> > Hey folks,
> >
> > I entered an issue (https://issues.apache.org/jira/browse/MINIFI-397) to
> > get this done and will initiate the associated ticket(s) with INFRA to
> make
> > this happen.
> >
> > --aldrin
> >
> > On Tue, Aug 22, 2017 at 12:00 PM, Andy Christianson <
> > achristian...@hortonworks.com> wrote:
> >
> >> +1
> >>
> >> On 8/22/17, 11:57 AM, "Kevin Doran"  wrote:
> >>
> >> Clones can cross projects. I'm a +1 for the suggestion of separate
> >> projects so as to keep a 1-to-1 between projects and repos. Related
> tickets
> >> can be linked or cloned to provide context when applicable.
> >>
> >> Thanks,
> >> Kevin
> >>
> >> On 8/22/17, 11:45, "Jeff Zemerick"  wrote:
> >>
> >> When I briefly looked through the tickets last week none stood
> >> out to me as
> >> applying to both projects. Granted, some potentially could like
> >> changing
> >> the Docker base image. With pull requests and GitHub I am of the
> >> opinion
> >> there should be a one-to-one-to-one correlation between ticket,
> >> pull
> >> request, and project. I know you can Clone a ticket but I don't
> >> know if
> >> it's possible to move the clone to a different project.
> >>
> >> On Tue, Aug 22, 2017 at 11:38 AM, Tony Kurc 
> >> wrote:
> >>
> >> > If there is a ticket that applies to multiple implementations,
> >> separate
> >> > jira projects makes that a bit more complicated. How often is
> >> that likely
> >> > to happen?
> >> >
> >> > On Tue, Aug 22, 2017 at 10:44 AM, Joe Witt <
> joe.w...@gmail.com>
> >> wrote:
> >> >
> >> > > Since changing the permissions on requirement for a given
> >> field and
> >> > > creating a new JIRA project both require ASF infra (i
> >> believe) then
> >> > > perhaps we should just go with the JIRA project route as
> that
> >> is
> >> > > cleaner/easier in the long run.
> >> > >
> >> > > What do ya'll think?
> >> > >
> >> > > On Tue, Aug 22, 2017 at 10:33 AM, Kevin Doran <
> >> kdoran.apa...@gmail.com>
> >> > > wrote:
> >> > > > I agree that would be an improvement to my suggestion of
> >> making the
> >> > > existing Component field required. As to feasibility, I
> leave
> >> that up to
> >> > > someone that has more experience working with ASF infra to
> >> administer
> >> > these
> >> > > ASF JIRA projects (Aldrin?).
> >> > > >
> >> > > > -Kevin
> >> > > >
> >> > > > On 8/21/17, 15:00, "Jeff Zemerick" 
> >> wrote:
> >> > > >
> >> > > > Would it be possible to use a JIRA custom field
> (that's
> >> required)
> >> > > called
> >> > > > "Implementation" or something similarly named with
> >> choices of C++
> >> > > and Java?
> >> > > > With more than just Java and C++ for components I'm
> >> afraid those
> >> > two
> >> > > > choices might be overlooked when a ticket is created.
> >> > > >
> >> > > > On Mon, Aug 21, 2017 at 11:37 AM, Andy Christianson <
> >> > > > achristian...@hortonworks.com> wrote:
> >> > > >
> >> > > > > Making it required sounds like an improvement, at
> the
> >> very least.
> >> > > > >
> >> > > > > -Andy I.C.
> >> > > >   

Re: Separate MiNiFi projects in JIRA

[Jeff Zemerick]

When I briefly looked through the tickets last week none stood out to me as
applying to both projects. Granted, some potentially could like changing
the Docker base image. With pull requests and GitHub I am of the opinion
there should be a one-to-one-to-one correlation between ticket, pull
request, and project. I know you can Clone a ticket but I don't know if
it's possible to move the clone to a different project.

On Tue, Aug 22, 2017 at 11:38 AM, Tony Kurc  wrote:

> If there is a ticket that applies to multiple implementations, separate
> jira projects makes that a bit more complicated. How often is that likely
> to happen?
>
> On Tue, Aug 22, 2017 at 10:44 AM, Joe Witt  wrote:
>
> > Since changing the permissions on requirement for a given field and
> > creating a new JIRA project both require ASF infra (i believe) then
> > perhaps we should just go with the JIRA project route as that is
> > cleaner/easier in the long run.
> >
> > What do ya'll think?
> >
> > On Tue, Aug 22, 2017 at 10:33 AM, Kevin Doran 
> > wrote:
> > > I agree that would be an improvement to my suggestion of making the
> > existing Component field required. As to feasibility, I leave that up to
> > someone that has more experience working with ASF infra to administer
> these
> > ASF JIRA projects (Aldrin?).
> > >
> > > -Kevin
> > >
> > > On 8/21/17, 15:00, "Jeff Zemerick"  wrote:
> > >
> > > Would it be possible to use a JIRA custom field (that's required)
> > called
> > > "Implementation" or something similarly named with choices of C++
> > and Java?
> > > With more than just Java and C++ for components I'm afraid those
> two
> > > choices might be overlooked when a ticket is created.
> > >
> > > On Mon, Aug 21, 2017 at 11:37 AM, Andy Christianson <
> > > achristian...@hortonworks.com> wrote:
> > >
> > > > Making it required sounds like an improvement, at the very least.
> > > >
> > > > -Andy I.C.
> > > > 
> > > > From: Kevin Doran 
> > > > Sent: Monday, August 21, 2017 11:22 AM
> > > > To: dev@nifi.apache.org
> > > > Subject: Re: Separate MiNiFi projects in JIRA
> > > >
> > > > Would  it suffice to make the existing 'component'  field
> > _required_ at
> > > > ticket creation time, and having components consist of 'C++',
> > 'Java', &
> > > > perhaps 'Both/All/*' as well? I imagine that is less effort than
> > setting up
> > > > and maintaining a separate project and solves the problem, unless
> > there are
> > > > advantages that a separate project would provide other than just
> > issue
> > > > filtering by C++/Java.
> > > >
> > > > Kevin
> > > >
> > > > On 8/21/17, 11:18, "Andy Christianson" <
> > achristian...@hortonworks.com>
> > > > wrote:
> > > >
> > > > Joe,
> > > >
> > > > We actually already have that. There is a 'C++' and 'Java'
> > component.
> > > > It works for the most part, but there are cases where it becomes
> > ambiguous,
> > > > particularly on docker-related tickets.
> > > >
> > > > I think there's certainly an argument that we need to just
> > track
> > > > components more carefully. Having it be a separate JIRA would
> make
> > it
> > > > harder to make a ticket ambiguous. Is it worth the
> effort/overhead
> > of
> > > > setting up another JIRA? I'll leave that to the more
> > > > experienced/established Apache parties since I don't know what
> the
> > overhead
> > > > cost is.
> > > >
> > > > Regards,
> > > >
> > > > Andy I.C.
> > > > 
> > > > From: Joe Witt 
> > > > Sent: Monday, August 21, 2017 11:10 AM
> > > > To: dev@nifi.apache.org
> > > > Subject: Re: Separate MiNiFi projects in JIRA
> > > >
> > > > Can we recommend and setup a set of component names so that
> > filtering
> > > >  

Re: Separate MiNiFi projects in JIRA

[Jeff Zemerick]

I'm +1 to that. Best long term method, I'd think.

On Tue, Aug 22, 2017 at 10:44 AM, Joe Witt  wrote:

> Since changing the permissions on requirement for a given field and
> creating a new JIRA project both require ASF infra (i believe) then
> perhaps we should just go with the JIRA project route as that is
> cleaner/easier in the long run.
>
> What do ya'll think?
>
> On Tue, Aug 22, 2017 at 10:33 AM, Kevin Doran 
> wrote:
> > I agree that would be an improvement to my suggestion of making the
> existing Component field required. As to feasibility, I leave that up to
> someone that has more experience working with ASF infra to administer these
> ASF JIRA projects (Aldrin?).
> >
> > -Kevin
> >
> > On 8/21/17, 15:00, "Jeff Zemerick"  wrote:
> >
> > Would it be possible to use a JIRA custom field (that's required)
> called
> > "Implementation" or something similarly named with choices of C++
> and Java?
> > With more than just Java and C++ for components I'm afraid those two
> > choices might be overlooked when a ticket is created.
> >
> > On Mon, Aug 21, 2017 at 11:37 AM, Andy Christianson <
> > achristian...@hortonworks.com> wrote:
> >
> > > Making it required sounds like an improvement, at the very least.
> > >
> > > -Andy I.C.
> > > 
> > > From: Kevin Doran 
> > > Sent: Monday, August 21, 2017 11:22 AM
> > > To: dev@nifi.apache.org
> > > Subject: Re: Separate MiNiFi projects in JIRA
> > >
> > > Would  it suffice to make the existing 'component'  field
> _required_ at
> > > ticket creation time, and having components consist of 'C++',
> 'Java', &
> > > perhaps 'Both/All/*' as well? I imagine that is less effort than
> setting up
> > > and maintaining a separate project and solves the problem, unless
> there are
> > > advantages that a separate project would provide other than just
> issue
> > > filtering by C++/Java.
> > >
> > > Kevin
> > >
> > > On 8/21/17, 11:18, "Andy Christianson" <
> achristian...@hortonworks.com>
> > > wrote:
> > >
> > > Joe,
> > >
> > > We actually already have that. There is a 'C++' and 'Java'
> component.
> > > It works for the most part, but there are cases where it becomes
> ambiguous,
> > > particularly on docker-related tickets.
> > >
> > > I think there's certainly an argument that we need to just
> track
> > > components more carefully. Having it be a separate JIRA would make
> it
> > > harder to make a ticket ambiguous. Is it worth the effort/overhead
> of
> > > setting up another JIRA? I'll leave that to the more
> > > experienced/established Apache parties since I don't know what the
> overhead
> > > cost is.
> > >
> > > Regards,
> > >
> > > Andy I.C.
> > > 
> > > From: Joe Witt 
> > > Sent: Monday, August 21, 2017 11:10 AM
> > > To: dev@nifi.apache.org
> > > Subject: Re: Separate MiNiFi projects in JIRA
> > >
> > > Can we recommend and setup a set of component names so that
> filtering
> > > can be done reasonably?
> > >
> > > If we do that would it be sufficient?
> > >
> > > Alternatively we can ask ASF infra to setup another JIRA
> project such
> > > as 'minificpp' but I'd like to avoid that until we're really
> sure we
> > > want to bug em.
> > >
> > > Thanks
> > >
> > > On Mon, Aug 21, 2017 at 11:03 AM, Andy Christianson
> > >  wrote:
> > > > Agree 100%. I have been bitten by this a few times. Is this
> > > something Aldrin can do/have done?
> > > >
> > > > -Andy I.C.
> > > > 
> > > > From: Jeff Zemerick 
> > > > Sent: Friday, August 18, 2017 2:56 PM
> > > > To: dev@nifi.apache.org
> > > > Subject: Separate MiNiFi projects in JIRA
> > > >
> > > > The MINIFI project in JIRA is currently a combination of
> issues for
> > > both
> > > > the C++ and Java implementations. Some issues for the C++
> project do
> > > have
> > > > the C++ component set but some don't and it can sometimes be
> hard to
> > > easily
> > > > differentiate the issues by their titles. (There isn't a
> "Java"
> > > component
> > > > so a useful filter is hard to make.) Has there been any
> > > consideration given
> > > > to having separate JIRA projects for the C++/Java MiNiFi
> > > implementations?
> > > >
> > > > Thanks,
> > > > Jeff
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>

Re: Separate MiNiFi projects in JIRA

[Jeff Zemerick]

Would it be possible to use a JIRA custom field (that's required) called
"Implementation" or something similarly named with choices of C++ and Java?
With more than just Java and C++ for components I'm afraid those two
choices might be overlooked when a ticket is created.

On Mon, Aug 21, 2017 at 11:37 AM, Andy Christianson <
achristian...@hortonworks.com> wrote:

> Making it required sounds like an improvement, at the very least.
>
> -Andy I.C.
> 
> From: Kevin Doran 
> Sent: Monday, August 21, 2017 11:22 AM
> To: dev@nifi.apache.org
> Subject: Re: Separate MiNiFi projects in JIRA
>
> Would  it suffice to make the existing 'component'  field _required_ at
> ticket creation time, and having components consist of 'C++', 'Java', &
> perhaps 'Both/All/*' as well? I imagine that is less effort than setting up
> and maintaining a separate project and solves the problem, unless there are
> advantages that a separate project would provide other than just issue
> filtering by C++/Java.
>
> Kevin
>
> On 8/21/17, 11:18, "Andy Christianson" 
> wrote:
>
> Joe,
>
> We actually already have that. There is a 'C++' and 'Java' component.
> It works for the most part, but there are cases where it becomes ambiguous,
> particularly on docker-related tickets.
>
> I think there's certainly an argument that we need to just track
> components more carefully. Having it be a separate JIRA would make it
> harder to make a ticket ambiguous. Is it worth the effort/overhead of
> setting up another JIRA? I'll leave that to the more
> experienced/established Apache parties since I don't know what the overhead
> cost is.
>
> Regards,
>
> Andy I.C.
> 
> From: Joe Witt 
> Sent: Monday, August 21, 2017 11:10 AM
> To: dev@nifi.apache.org
> Subject: Re: Separate MiNiFi projects in JIRA
>
> Can we recommend and setup a set of component names so that filtering
> can be done reasonably?
>
> If we do that would it be sufficient?
>
> Alternatively we can ask ASF infra to setup another JIRA project such
> as 'minificpp' but I'd like to avoid that until we're really sure we
> want to bug em.
>
> Thanks
>
> On Mon, Aug 21, 2017 at 11:03 AM, Andy Christianson
>  wrote:
> > Agree 100%. I have been bitten by this a few times. Is this
> something Aldrin can do/have done?
> >
> > -Andy I.C.
> > 
> > From: Jeff Zemerick 
> > Sent: Friday, August 18, 2017 2:56 PM
> > To: dev@nifi.apache.org
> > Subject: Separate MiNiFi projects in JIRA
> >
> > The MINIFI project in JIRA is currently a combination of issues for
> both
> > the C++ and Java implementations. Some issues for the C++ project do
> have
> > the C++ component set but some don't and it can sometimes be hard to
> easily
> > differentiate the issues by their titles. (There isn't a "Java"
> component
> > so a useful filter is hard to make.) Has there been any
> consideration given
> > to having separate JIRA projects for the C++/Java MiNiFi
> implementations?
> >
> > Thanks,
> > Jeff
> >
> >
>
>
>
>
>
>
>
>
>

Separate MiNiFi projects in JIRA

[Jeff Zemerick]

The MINIFI project in JIRA is currently a combination of issues for both
the C++ and Java implementations. Some issues for the C++ project do have
the C++ component set but some don't and it can sometimes be hard to easily
differentiate the issues by their titles. (There isn't a "Java" component
so a useful filter is hard to make.) Has there been any consideration given
to having separate JIRA projects for the C++/Java MiNiFi implementations?

Thanks,
Jeff

Processor for Apache Rya

[Jeff Zemerick]

I have a processor that ingests triples to Apache Rya. Would it be ok to
work on a pull request to include this processor in NiFi? (I guess what I
am asking more broadly is if there is any selection criteria that
determines what processors are included in NiFi?)

Thanks,
Jeff

Re: [DISCUSS] Apache Gitbox

[Jeff Zemerick]

Also from OpenNLP -- yes, the workflow is much simpler and faster. I highly
recommend it.

On Fri, Jul 28, 2017 at 3:00 PM, Suneel Marthi  wrote:

> We migrated Apache OpenNLP to gitbox (beginning of July) and even had a
> release immediately.
>
> Yes, the PR commit workflow is lot simpler now with gitbox (just a button
> click).
>
> I would definitely recommend moving Nifi to gitbox, if anything it makes a
> committer's life lot easier.
>
>
> Before Gitbox, this is how PRs were merged:
>
>  http://mahout.apache.org/developers/github.html
>
> After Gitbox, this is how it will be:
>
> http://opennlp.apache.org/using-git.html
>
>
>
>
> On Fri, Jul 28, 2017 at 2:52 PM, Aldrin Piri  wrote:
>
> > Hey folks,
> >
> > I saw mention on the Incubator general mailing list about Gitbox [1].
> From
> > that message it seems like it would help considerably with some of the
> > maintenance tasks we perform on the repository.  Has anyone in the
> > community used it on another project and have any opinions on it?
> >
> > Doing some searching, I was able to find some discussion from the
> Accumulo
> > project [2].
> >
> > With my very basic understanding of the service, it seems like it would
> be
> > a welcomed bit of functionality.
> >
> > Is this something we think is worth exploring further and enabling on our
> > repositories?
> >
> > [1] https://lists.apache.org/thread.html/Znkiyqnxqzryecv
> > [2] http://apache-accumulo.1065345.n5.nabble.com/DISCUSS-
> > GitBox-td21160.html
> >
>

Re: MiNiFi Java as Windows Service

[Jeff Zemerick]

I submitted a pull request for running MiNiFi as a Windows service using
Commons Daemon's Procrun. Like winsw it supports more than just Java
applications so it should work for the C++ version as well. I went with it
due to it also being ASL and just due to personal familiarity. If there's a
strong desire for winsw instead let me know!

Since our edge locations are Windows environments I have also created a
Windows setup for MiNiFi using InnoSetup. The setup copies the required
files, installs the service, and removes the service when uninstalled. The
setup is buildable through Maven with a profile I added to the
minifi-assembly project (assuming InnoSetup is on your computer). If you
think there might be a broad appeal for this I'll be happy to make a pull
request for it.

Thanks,
Jeff


On Mon, Jun 26, 2017 at 6:13 PM, Jeff Zemerick  wrote:

> Thanks everyone! I will make a JIRA task and look over the shared links.
>
> Jeff
>
>
> On Mon, Jun 26, 2017 at 2:57 PM, Bryan Rosander 
> wrote:
>
>> +1
>>
>> It looks like winsw would be a good option.  I noticed it also supports
>> arbitrary executables, not just Java programs.  That would mean we could
>> use it for both C++ and Java implementations unless there's a good reason
>> not to (once C++ version can run on Windows).
>>
>> On Mon, Jun 26, 2017 at 2:45 PM, Joey Frazee 
>> wrote:
>>
>> > Jefff, there was a related thread about this a few months back:
>> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
>> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E <
>> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
>> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E>
>> >
>> > In that, Andre suggested an approach using https://github.com/kohsuke/
>> > winsw <https://github.com/kohsuke/winsw> and maybe he has a branch
>> > already, but anything with a compatible license will certainly be a
>> great
>> > contribution.
>> >
>> > I’m sure me and him, and others are very interested in this.
>> >
>> > -joey
>> >
>> > > On Jun 26, 2017, at 1:17 PM, Aldrin Piri 
>> wrote:
>> > >
>> > > Hi Jeff,
>> > >
>> > > A PR would most certainly be welcomed and (likely could be an easy win
>> > for
>> > > NiFi as well).  The only caveat to be mindful of is that any
>> > > frameworks/tools/utilities should be friendly with ALv2 terms as per
>> > > http://www.apache.org/legal/resolved.html.   If you have any
>> particular
>> > > items in mind and are unsure, please feel free to follow up on here
>> and
>> > we
>> > > can work though what licensing looks like.
>> > >
>> > > On Mon, Jun 26, 2017 at 2:12 PM, Jeff Zemerick 
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I see a ticket to make the C++ version run as a Windows service
>> > >> (MINIFI-89). Is there a recommended method of running the Java
>> version
>> > as a
>> > >> Windows service? If not, would there be any interest in a pull
>> request
>> > to
>> > >> add that functionality?
>> > >>
>> > >> Thanks,
>> > >> Jeff
>> > >>
>> >
>> >
>>
>
>

Re: MiNiFi Java as Windows Service

[Jeff Zemerick]

Thanks everyone! I will make a JIRA task and look over the shared links.

Jeff


On Mon, Jun 26, 2017 at 2:57 PM, Bryan Rosander 
wrote:

> +1
>
> It looks like winsw would be a good option.  I noticed it also supports
> arbitrary executables, not just Java programs.  That would mean we could
> use it for both C++ and Java implementations unless there's a good reason
> not to (once C++ version can run on Windows).
>
> On Mon, Jun 26, 2017 at 2:45 PM, Joey Frazee 
> wrote:
>
> > Jefff, there was a related thread about this a few months back:
> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E <
> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E>
> >
> > In that, Andre suggested an approach using https://github.com/kohsuke/
> > winsw <https://github.com/kohsuke/winsw> and maybe he has a branch
> > already, but anything with a compatible license will certainly be a great
> > contribution.
> >
> > I’m sure me and him, and others are very interested in this.
> >
> > -joey
> >
> > > On Jun 26, 2017, at 1:17 PM, Aldrin Piri  wrote:
> > >
> > > Hi Jeff,
> > >
> > > A PR would most certainly be welcomed and (likely could be an easy win
> > for
> > > NiFi as well).  The only caveat to be mindful of is that any
> > > frameworks/tools/utilities should be friendly with ALv2 terms as per
> > > http://www.apache.org/legal/resolved.html.   If you have any
> particular
> > > items in mind and are unsure, please feel free to follow up on here and
> > we
> > > can work though what licensing looks like.
> > >
> > > On Mon, Jun 26, 2017 at 2:12 PM, Jeff Zemerick 
> > wrote:
> > >
> > >> Hi,
> > >>
> > >> I see a ticket to make the C++ version run as a Windows service
> > >> (MINIFI-89). Is there a recommended method of running the Java version
> > as a
> > >> Windows service? If not, would there be any interest in a pull request
> > to
> > >> add that functionality?
> > >>
> > >> Thanks,
> > >> Jeff
> > >>
> >
> >
>

MiNiFi Java as Windows Service

[Jeff Zemerick]

Hi,

I see a ticket to make the C++ version run as a Windows service
(MINIFI-89). Is there a recommended method of running the Java version as a
Windows service? If not, would there be any interest in a pull request to
add that functionality?

Thanks,
Jeff

Re: [VOTE] Release Apache NiFi MiNiFi 0.2.0

[Jeff Zemerick]

+1 (non-binding)

Build/tests with contrib-check
Ran and successfully tested a simple flow

On Tue, May 16, 2017 at 12:54 PM, Marc  wrote:

> +1 non-binding
>
>   Verified sigs && hashes.
>
>Built and ran test flows that I used for MiNiFi-C++ to include Site to
> Site, and a handful of processors to verify functionality.
>
>Looks good!
>
>-- Marc
>
> On Tue, May 16, 2017 at 11:55 AM, Aldrin Piri 
> wrote:
>
> > +1, binding
> >
> > Remarks
> > Signatures, hashes, and build looked good
> > Ran the test flow used as a sample in C++ and verified site to site
> > functionality. Spun up C2 server and did checks over basic interactions
> in
> > pulling new flows
> > We could use some additional documentation moving forward for C2 and
> > supported features across implementations.  Created JIRAs to track these
> > efforts, MINIFI-315 [1] and MINIFI-316 [2], respectively.
> >
> >
> > [1] https://issues.apache.org/jira/browse/MINIFI-315
> > [2] https://issues.apache.org/jira/browse/MINIFI-316
> >
> > On Tue, May 16, 2017 at 10:45 AM, Joe Witt  wrote:
> >
> > > +1 (binding)
> > >
> > > Verified sigs/hashes/full build w/contrib check/test flow/license and
> > > notices.
> > >
> > > Thanks for the great efforts here all!
> > >
> > > On Mon, May 15, 2017 at 12:55 PM, Aldrin Piri 
> wrote:
> > > > Hello,
> > > >
> > > > I am pleased to be calling this vote for the source release of Apache
> > > NiFi MiNiFi, minifi-0.2.0.
> > > >
> > > > The source zip, including signatures, digests, etc. can be found at:
> > > > https://repository.apache.org/content/repositories/
> orgapachenifi-1107
> > > >
> > > > The Git tag is minifi-0.2.0-RC1
> > > > The Git commit ID is 1813e87ccddffcc9ab75d25948c31901faf2f1ab
> > > > * https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=
> > commit;h=
> > > 1813e87ccddffcc9ab75d25948c31901faf2f1ab
> > > > * https://github.com/apache/nifi-minifi/commit/
> > > 1813e87ccddffcc9ab75d25948c31901faf2f1ab
> > > >
> > > > Checksums of minifi-0.2.0-source-release.zip:
> > > > MD5:  e0f9bbd7afeb9547126a710b3e30face
> > > > SHA1:  bcba77ccd4254de3275ecb2a732005e6b404706d
> > > > SHA256:  c182d71ba298a41a336da139f435f1
> 0a253997d677fc4ae8820b261ea8c3
> > > a4c2
> > > > Release artifacts are signed with the following key:
> > > > https://people.apache.org/keys/committer/aldrin.asc
> > > >
> > > > KEYS file available here:
> > > > https://dist.apache.org/repos/dist/release/nifi/KEYS
> > > >
> > > > 26 issues were closed/resolved for this release:
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > version=12338791&projectId=12319921
> > > >
> > > > Release note highlights can be found here:
> > > > https://cwiki.apache.org/confluence/display/MINIFI/
> > > Release+Notes#ReleaseNotes-Version0.2.0
> > > >
> > > > The vote will be open for at least 72 hours and close at 5PM EDT, 18
> > May
> > > 2017 [1].
> > > >
> > > > Please download the release candidate and evaluate the necessary
> items
> > > including checking hashes, signatures, build
> > > > from source, and test.  Then please vote:
> > > >
> > > > [ ] +1 Release this package as minifi-0.2.0
> > > > [ ] +0 no opinion
> > > > [ ] -1 Do not release this package because...
> > > >
> > > > Thanks!
> > > >
> > > > [1] You can determine this time for your local time zone at
> > > https://s.apache.org/minifi-0.2.0-rc1-close
> > >
> >
>

Re: [VOTE] Release Apache NiFi 1.2.0 (RC2)

[Jeff Zemerick]

+1 non-binding

Full contrib-check build on clean Ubuntu 16.04 image.
Tested with some simple flows.

A few sparse, intermittent unit test failures were added to JIRA.

Jeff


On Sun, May 7, 2017 at 8:27 AM, Matt Gilman  wrote:

> +1 binding
>
> Verified hashes, signatures, etc
> Full build with contrib-check
>
> Ran various configurations clustered vs standalone, secured vs unsecured,
> different authentication strategies, etc. Also made sure that issues
> discovered during VOTE of RC1 were corrected.
>
> Thanks
>
> Matt
>
> On Sun, May 7, 2017 at 1:36 AM, Koji Kawamura 
> wrote:
>
> > +1 (non-binding)
> > Full build with contrib check passed on Mac OS X
> > Tested "Provenance Stream Record ReaderWriter" template, and other new
> > features
> >
> > Thanks,
> > Koji
> >
> > On Sun, May 7, 2017 at 7:43 AM, Richard St. John 
> > wrote:
> > > +1 non-binding
> > > Built RPM on CentOS 6
> > > Installed RPM on Amazon Linux
> > > FlowFile from 1.1.x worked on 1.2.0
> > >
> > > Rick
> > >
> > > On Sat, May 6, 2017, 12:39 PM Haimo Liu  wrote:
> > >
> > >> +1 non-binding, release this as Apache NiFi 1.2.0
> > >>
> > >> Tested full clean install on OSX
> > >>
> > >> Tested RecordReader/Writer flow
> > >> Tested CDC flow (MySql DB1 as source, MySql DB2 as target)
> > >>
> > >>
> > >>
> > >> On May 6, 2017 11:40 AM, "Joe Witt"  wrote:
> > >>
> > >> +1 (binding).
> > >>
> > >>
> > >> Full clean build w/contrib check on OSX, Linux 3.10
> > >> Builds clean on Windows10 but there are test failures due to os
> > >> compatibility issues with the test.
> > >>
> > >> Tested the application on Windows, Linux and OSX.  All looks solid.
> > >> License/Notice looks good.
> > >>
> > >> Provided a detailed template flow and instructions to use the new
> > >> record reader/writer capability with internal schema registry to
> > >> acquire, filter, and convert NiFi's own provenance stream into JSON,
> > >> Avro, XML and CSV at once.
> > >> https://cwiki.apache.org/confluence/display/NIFI/
> > Example+Dataflow+Templates
> > >>
> > >> This is a really impressive release with tremendous community
> > >> engagement!  Thanks all
> > >>
> > >> Joe
> > >>
> > >> On Fri, May 5, 2017 at 10:07 PM, Bryan Bende 
> wrote:
> > >> > Hello,
> > >> >
> > >> > I am pleased to be calling this vote for the source release of
> Apache
> > >> > NiFi nifi-1.2.0 (RC2).
> > >> >
> > >> > The source zip, including signatures, digests, etc. can be found at:
> > >> > https://repository.apache.org/content/repositories/
> orgapachenifi-1104
> > >> >
> > >> > The Git tag is nifi-1.2.0-RC2
> > >> > The Git commit ID is 3a605af8e0ac024fb0ba67262d49dab2727b2576
> > >> > https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> > >> 3a605af8e0ac024fb0ba67262d49dab2727b2576
> > >> >
> > >> > Checksums of nifi-1.2.0-source-release.zip:
> > >> > MD5: 90e298a9e23a9dab65358daddd8b5990
> > >> > SHA1: e138941f576bdb1dff17df6674c19ffae3ef6719
> > >> > SHA256: c18398800c435dabff9f45ec55a450
> ca78c3c1aec222aa295c0e2057912f
> > eeb6
> > >> >
> > >> > Release artifacts are signed with the following key:
> > >> > https://people.apache.org/keys/committer/bbende.asc
> > >> >
> > >> > KEYS file available here:
> > >> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> > >> >
> > >> > 381 issues were closed/resolved for this release:
> > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > >> projectId=12316020&version=12338432
> > >> >
> > >> > Release note highlights can be found here:
> > >> > https://cwiki.apache.org/confluence/display/NIFI/
> > >> Release+Notes#ReleaseNotes-Version1.2.0
> > >> >
> > >> > The vote will be open for 72 hours.
> > >> > Please download the release candidate and evaluate the necessary
> items
> > >> > including checking hashes, signatures, build
> > >> > from source, and test.  The please vote:
> > >> >
> > >> > [ ] +1 Release this package as nifi-1.2.0
> > >> > [ ] +0 no opinion
> > >> > [ ] -1 Do not release this package because because...
> > >>
> > > --
> > >
> > > 
> > > Richard St. John, Ph.D.
> > > Senior Software Engineer, Applied Mathematician
> > > Asymmetrik, Ltd.
> >
>

Re: seemingly random junit test errors in 1.2.0-source-release

[Jeff Zemerick]

Thanks, Joe! I will document them.

Jeff

On Fri, May 5, 2017 at 10:19 AM, Joe Witt  wrote:

> Jeff
>
> We have test quality challenges in my opinion.  Not new to this release at
> all but we did correct or isolate a lot of tests in this release cycle.
> Please feel free to file jiras for unstable tests as you find them.  We
> want unit tests that will prove behavior, verify no regressions, run
> fast/quickly, aren't relying on magic threading timing, avoid
> integration/sockets/etc..
>
> I too have seen the behaviors you describe on some tests and on different
> systems.  Happily this release I find far better than previous ones but we
> still have work to do for sure.
>
> Thanks
> Joe
>
>
> On May 5, 2017 10:14 AM, "Jeff Zemerick"  wrote:
>
> I'm getting a few random test errors when building the 1.2.0 source
> release. The failures seem to be completely random. I have built many times
> per the steps below and most times everything is ok but every now and then
> one of the tests fails. I can't reproduce any of them in Maven or Eclipse.
>
> Here are my steps:
>
> 1. Provision a new Ubuntu 16 VM (t2.small on EC2).
> 2. wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.2.0/nifi-
> 1.2.0-source-release.zip
> 3. unzip nifi-1.2.0-source-release.zip
> 4. cd nifi-1.2.0-source-release
> 5. mvn clean install -Pcontrib-check
>
> Other details:
>
> Apache Maven 3.3.9
> openjdk version "1.8.0_121"
> Ubuntu 16.04.2 LTS
>
> The failing tests (Note that all 3 of these failed separately across
> different builds and not in any single build):
>
> Running org.apache.nifi.controller.scheduling.TestStandardProcessScheduler
> Tests run: 9, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 16.091 sec
> <<< FAILURE! - in
> org.apache.nifi.controller.scheduling.TestStandardProcessScheduler
> validateServiceEnablementLogicHappensOnlyOnce(org.apache.
> nifi.controller.scheduling.TestStandardProcessScheduler)
>  Time elapsed: 0.824 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.nifi.controller.scheduling.TestStandardProcessScheduler.
> validateServiceEnablementLogicHappensOnlyOnce(TestStandardPr
> ocessScheduler.
> java:266)
>
> Running
> org.apache.nifi.controller.service.TestStandardControllerServiceProvider
> Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 125.657 sec
> <<< FAILURE! - in
> org.apache.nifi.controller.service.TestStandardControllerServiceProvider
> testConcurrencyWithEnablingReferencingServicesGraph(org.
> apache.nifi.controller.service.TestStandardControllerServiceProvider)
>  Time elapsed: 120.098 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 12
> milliseconds
> at java.util.HashMap.putVal(HashMap.java:630)
> at java.util.HashMap.put(HashMap.java:611)
> at java.util.HashSet.add(HashSet.java:219)
> at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUt
> ils.java:470)
> at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUt
> ils.java:471)
> at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUt
> ils.java:454)
> at
> org.apache.nifi.controller.service.StandardControllerServiceProvi
> der.createControllerService(StandardControllerServiceProvider.java:126)
> at
> org.apache.nifi.controller.service.TestStandardControllerServiceProvider.
> testEnableReferencingServicesGraph(TestStandardControllerServiceP
> rovider.java:214)
> at
> org.apache.nifi.controller.service.TestStandardControllerServiceProvider.
> testConcurrencyWithEnablingReferencingServicesGraph(
> TestStandardControllerServiceProvider.java:188)
>
> Running org.apache.nifi.controller.scheduling.TestProcessorLifecycle
> Tests run: 16, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 47.215 sec
> <<< FAILURE! - in
> org.apache.nifi.controller.scheduling.TestProcessorLifecycle
> validateProcessScheduledAfterAdministrativeDelayDueToTheOnSc
> heduledException(org.apache.nifi.controller.scheduling.
> TestProcessorLifecycle)
>  Time elapsed: 3.981 sec  <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.nifi.controller.scheduling.TestProcessorLifecycle.
> validateProcessScheduledAfterAdministrativeDelayDueToTheOnSc
> heduledException(TestProcessorLifecycle.java:373)
>
> Any ideas? Could an EC2 t2.small (2 GB RAM) be insufficient for the build?
>
> Thanks,
> Jeff
>

seemingly random junit test errors in 1.2.0-source-release

[Jeff Zemerick]

I'm getting a few random test errors when building the 1.2.0 source
release. The failures seem to be completely random. I have built many times
per the steps below and most times everything is ok but every now and then
one of the tests fails. I can't reproduce any of them in Maven or Eclipse.

Here are my steps:

1. Provision a new Ubuntu 16 VM (t2.small on EC2).
2. wget https://dist.apache.org/repos/dist/dev/nifi/nifi-1.2.0/nifi-
1.2.0-source-release.zip
3. unzip nifi-1.2.0-source-release.zip
4. cd nifi-1.2.0-source-release
5. mvn clean install -Pcontrib-check

Other details:

Apache Maven 3.3.9
openjdk version "1.8.0_121"
Ubuntu 16.04.2 LTS

The failing tests (Note that all 3 of these failed separately across
different builds and not in any single build):

Running org.apache.nifi.controller.scheduling.TestStandardProcessScheduler
Tests run: 9, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 16.091 sec
<<< FAILURE! - in
org.apache.nifi.controller.scheduling.TestStandardProcessScheduler
validateServiceEnablementLogicHappensOnlyOnce(org.apache.nifi.controller.scheduling.TestStandardProcessScheduler)
 Time elapsed: 0.824 sec  <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at
org.apache.nifi.controller.scheduling.TestStandardProcessScheduler.validateServiceEnablementLogicHappensOnlyOnce(TestStandardProcessScheduler.java:266)

Running
org.apache.nifi.controller.service.TestStandardControllerServiceProvider
Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 125.657 sec
<<< FAILURE! - in
org.apache.nifi.controller.service.TestStandardControllerServiceProvider
testConcurrencyWithEnablingReferencingServicesGraph(org.apache.nifi.controller.service.TestStandardControllerServiceProvider)
 Time elapsed: 120.098 sec  <<< ERROR!
org.junit.runners.model.TestTimedOutException: test timed out after 12
milliseconds
at java.util.HashMap.putVal(HashMap.java:630)
at java.util.HashMap.put(HashMap.java:611)
at java.util.HashSet.add(HashSet.java:219)
at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUtils.java:470)
at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUtils.java:471)
at org.apache.commons.lang3.ClassUtils.getAllInterfaces(ClassUtils.java:454)
at
org.apache.nifi.controller.service.StandardControllerServiceProvider.createControllerService(StandardControllerServiceProvider.java:126)
at
org.apache.nifi.controller.service.TestStandardControllerServiceProvider.testEnableReferencingServicesGraph(TestStandardControllerServiceProvider.java:214)
at
org.apache.nifi.controller.service.TestStandardControllerServiceProvider.testConcurrencyWithEnablingReferencingServicesGraph(TestStandardControllerServiceProvider.java:188)

Running org.apache.nifi.controller.scheduling.TestProcessorLifecycle
Tests run: 16, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 47.215 sec
<<< FAILURE! - in
org.apache.nifi.controller.scheduling.TestProcessorLifecycle
validateProcessScheduledAfterAdministrativeDelayDueToTheOnScheduledException(org.apache.nifi.controller.scheduling.TestProcessorLifecycle)
 Time elapsed: 3.981 sec  <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.nifi.controller.scheduling.TestProcessorLifecycle.validateProcessScheduledAfterAdministrativeDelayDueToTheOnScheduledException(TestProcessorLifecycle.java:373)

Any ideas? Could an EC2 t2.small (2 GB RAM) be insufficient for the build?

Thanks,
Jeff