Re: [VOTE] Adopt NiFi 2.0 Proposed Release Goals

[Tony Kurc]

+1 (binding)

On Mon, Dec 12, 2022, 12:02 PM David Handermann 
wrote:

> Team,
>
> Following positive feedback on NiFi 2.0 Proposed Release Goals [1] on the
> recent discussion thread [2], I am calling this vote to adopt the following
> as Release Goals for NiFi 2.0:
>
> 1. Remove Java 8 support and require Java 11
> 2. Remove deprecated components
> 3. Remove deprecated component properties
> 4. Remove components integrating with unmaintained services
> 5. Remove compatibility classes and methods
> 6. Remove flow.xml.gz in favor of flow.json.gz
> 7. Remove duplicative features
> 8. Upgrade internal Java API references
> 9. Reorganize standard components
> 10. Implement migration tools for upgrading flows
>
> A positive vote indicates agreement on these goals and the initiation of
> the following actions:
>
> 1. Rename NiFi 2.0 Proposed Release Goals to NiFi 2.0 Release Goals
> 2. Create version 1 branch in Git for subsequent support releases on the
> version 1 series
> 3. Update the current main branch in Git to version 2.0.0-SNAPSHOT
>
> The vote will be open for 72 hours and follow standard procedures for
> release votes.
>
> Please review the linked goals and discussions for background.
>
> [ ] +1 Adopt NiFi 2.0 Release Goals
> [ ] +0 No opinion
> [ ] -1 Do not adopt NiFi 2.0 Release Goals for the following reasons...
>
> [1]
>
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> [2] https://lists.apache.org/thread/xo77p9t3xg4k70356xrqbdg4m9sg7sf8
>

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.12.0 (RC1)

[Tony Kurc]

+1 (binding)

Verified signature, hashes, didn't see issues with LICENSE or NOTICE aside
from what Joe mentioned.

Build was a little bit of a challenge because of my environment (had some
weird issues with dependency versions (MX Linux)), but powered through to a
successful build and test.

Tony


On Tue, May 24, 2022 at 6:10 PM Joe Witt  wrote:

> +1 binding.
>
> Sigs, hashes, L overall look good (very thorough on L!)
>
> Need to fix the copyright year in NOTICE as it currently lists 2019.
>
> Thanks
>
> On Tue, May 24, 2022 at 12:04 PM Marc Parisi  wrote:
>
> > +1
> >
> > verified sigs and hashes.
> >
> > Ran a simple flow, starting, stopping, and changing flow with c2
> protocol.
> >
> > Everything looks good. Great stuff!
> >
> > Thanks,
> > Marc
> >
> >
> >
> > On Tue, May 24, 2022 at 9:56 AM Martin Zink 
> wrote:
> >
> > > Good idea, I've renamed the convenience binary
> > >
> > > On Tue, May 24, 2022 at 2:54 PM Marton Szasz 
> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > Ran through the release helper guide. Tested the convenience binaries
> > > > with a RPG to the NiFi release candidate, then InvokeHTTP to another
> > > > MiNiFi C++ RC agent that I've built myself.
> > > >
> > > > I would rename the convenience binary package from
> > > > nifi-minifi-cpp-0.12.0-bin-centos.tar.gz to
> > > > nifi-minifi-cpp-0.12.0-bin-linux.tar.gz before finishing the release,
> > > > since it works on basically all major linux distros, even though it's
> > > > built on CentOS. We did the same with 0.11.0.
> > > >
> > > > Thanks!
> > > >
> > > > On Mon, 23 May 2022 at 13:28, Ferenc Gerlits 
> > > wrote:
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > I have
> > > > > * verified the checksums and signatures
> > > > > * compared the contents of the source tarball to the
> > > > minifi-cpp-0.12.0-RC1
> > > > > tag in git
> > > > > * ran the binary with a simple GenerateFlowFile -> LogAttribute
> flow,
> > > > with
> > > > > heartbeat logging on
> > > > > * connected to C2
> > > > >
> > > > > Everything worked correctly.
> > > > >
> > > > > Thanks,
> > > > > Ferenc
> > > >
> > >
> >
>

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

[Tony Kurc]

+1 (binding)

Verified hashes and signatures. Reviewed notice and license and readme and
did not see any issues. Build went without issue and ran a simple flow.

Tony


On Mon, Mar 21, 2022, 5:42 PM Joe Witt  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.16.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1198
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.16.0/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.16.0-RC3
> The Git commit ID is b019a9191f1c83bc7f547dc02c1b679b8936acee
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=b019a9191f1c83bc7f547dc02c1b679b8936acee
>
> Checksums of nifi-1.16.0-source-release.zip:
> SHA256: 2f16cb94df404d1bcc9c32835ba98da8940005a5d7ea5504c155ee42021a221e
> SHA512:
>
> cbd95f15cec5ffe506fef204526267b18b77d7266f6dc3e1bbc3c7600aac12e119977f7d8cf93dbbbc86fbb0739ba88aaa11a5381d29a463ec9a0c9a18f4e9e6
>
> 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
>
> 401 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12350741
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.16.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.16.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi 1.15.3 (rc1)

[Tony Kurc]

+1 (binding)


Verified sign/hash. Build without issue. Notice and license files look good.

On Tue, Jan 18, 2022, 11:08 AM Mark Payne  wrote:

> +1 (binding)
>
> - Verified the hashes
> - Build on Java 8, mac os Big Sur
> - Ran all system tests (including nifi stateless system tests) and all
> completed successfully
> - Performed some simple smoke screen tests manually
> - All looks good to me, ran into no issues.
>
> Thanks
> -Mark
>
>
>
> > On Jan 13, 2022, at 3:44 PM, Joe Witt  wrote:
> >
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> > NiFi 1.15.3.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1194
> >
> > The source being voted upon and the convenience binaries can be found at:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.3/
> >
> > A helpful reminder on how the release candidate verification process
> works:
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> >
> > The Git tag is nifi-1.15.3-RC1
> > The Git commit ID is 753c311382005acadc16c64952d7b1eaaf2550d5
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=753c311382005acadc16c64952d7b1eaaf2550d5
> >
> > Checksums of nifi-1.15.3-source-release.zip:
> > SHA256: 29fcc35c81de80e0fe3f59044e6fbf21bcf523e656aa64914e7546e1d7705e6b
> > SHA512:
> cabd1f1ad4942a61df0400488d35521202598c217ad8da97dc2d5abe21136604d1f1bb3de9ceb63bb441943de2e29e3515f5cf63607080094e1418d79eb5216b
> >
> > 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
> >
> > 11 issues were closed/resolved for this release:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12351203
> >
> > Release note highlights can be found here:
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.15.3
> >
> > The vote will be open
> > 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.15.3
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
>
>

Re: [VOTE] Release Apache NiFi 1.15.2

[Tony Kurc]

+1 (binding)

Verified signatures and hashes, and built without issue.

On Wed, Dec 22, 2021 at 9:39 AM Matt Gilman  wrote:

> +1 (binding) Release this package as nifi-1.15.2
>
> Ran through the release helper. Looks great. Thanks for RMing Joe!
>
> Matt
>
> On Tue, Dec 21, 2021 at 5:52 PM Joe Witt  wrote:
>
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> > NiFi 1.15.2.
> >
> > This vote is purely bug fix and security focused. This is a
> > continuation of our efforts to promptly and thoroughly respond to
> > log4shell and related concerns.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1193
> >
> > The source being voted upon and the convenience binaries can be found at:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.2/
> >
> > A helpful reminder on how the release candidate verification process
> works:
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> >
> > The Git tag is nifi-1.15.2-RC1
> > The Git commit ID is 1ea460b8556b07057366abb74a5552ace8946e87
> >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=1ea460b8556b07057366abb74a5552ace8946e87
> >
> > Checksums of nifi-1.15.2-source-release.zip:
> > SHA256: 29fcc35c81de80e0fe3f59044e6fbf21bcf523e656aa64914e7546e1d7705e6b
> > SHA512:
> >
> cabd1f1ad4942a61df0400488d35521202598c217ad8da97dc2d5abe21136604d1f1bb3de9ceb63bb441943de2e29e3515f5cf63607080094e1418d79eb5216b
> >
> > 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
> >
> > 8 issues were closed/resolved for this release:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12351132
> >
> > Release note highlights can be found here:
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.15.2
> >
> > Given the nature of the vote and its limited scope
> > the vote will be open for 24 hours or until we have sufficient
> > votes (instead of the normal 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.15.2
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
>

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

[Tony Kurc]

+1 (binding)

Struggled a bit to build on my rig, primarily due to environment issues
more than anything else (older Ubuntu), but did build successfully and made
working binary build (tested very simple flow). Verified signature and
hashes, and saw no issues with LICENSE, NOTICE.

On Sat, Nov 6, 2021 at 3:58 PM Kevin Doran  wrote:

> +1 (binding)
>
> - Verified sigs and hashes (see note below)
> - Built from source
> - Built docker images for nifi, registry, minifi, minifi-c2, nifi-toolkit
> - Ran nifi and nifi-registry in docker compose
> - Used nifi to create a versioned PG to save to registry
> - Used minify-toolkit to test converting PG from json and xml to yaml
> - Used minifi-c2 convienence binary to host resulting yaml
> - Tested MiNiFi java to pull config.yml from minifi-c2 server using
> PullHttpChangeIngestor
>
> One important note for Joe:
>
> For the convenience binaries, minifi-c2-1.15.0-bin.tar.gz.sha256 and
> minifi-c2-1.15.0-bin.zip.sha256 hashes do not match SHA 256 hash digests.
> They contain the sha512 values. Those file names should be updated to
> minifi-c2-1.15.0-bin.tar.gz.sha512 and minifi-c2-1.15.0-bin.zip.sha512
> assuming this RC passes.
>
> Other observations
>
> - NiFi docker readme instructions should updated for sensitive properties
> keys. I will do this as part of pushing docker images to docker hub
> following the 1.15 release
> - NiFi Registry Dockerfile needs to add a step to chmod +x the startup
> script, in case it is not in the source checkout. I will open a jira for
> this.
>
> Thanks all!
> Kevin
>
>
> > On Nov 5, 2021, at 17:58, Marton Szasz  wrote:
> >
> > +1 (binding)
> >
> > Followed the release helper guide, tested systemd-journald message
> > collection from three minifi c++ linux agents to a single nifi
> > instance via putudp/listenudp.
> > Environment:
> > Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
> > Maven home: /usr/share/maven-bin-3.8
> > Java version: 1.8.0_252, vendor: IcedTea, runtime:
> /opt/icedtea-bin-3.16.0/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.14.14-gentoo-x86_64", arch: "amd64",
> > family: "unix"
> >
> > Marton
> >
> > On Fri, 5 Nov 2021 at 21:33, Joey Frazee 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> - Verified signatures and checksums (except for prior comment on
> minifi-c2)
> >> - Ran full build on Linux with Java 1.8.0_292
> >> - Ran various flows and ITs
> >> - Built and ran dockermaven Docker build
> >>
> >> -joey
> >>
> >>> On Nov 5, 2021, at 1:50 PM, Andrew Lim 
> wrote:
> >>>
> >>> +1 (binding)
> >>>
> >>> -Ran full clean install on OS X (Catalina 10.15.2, OpenJDK version
> 1.8.0_252)
> >>> -Tested secure NiFi with secure NiFi Registry
> >>> -Ran basic flows successfully; tested basic versioned flow
> functionality
> >>> -Reviewed UI fixes and documentation updates
> >>>
> >>> Drew
> >>>
>  On Nov 3, 2021, at 3:29 PM, Joe Witt  wrote:
> 
>  Hello,
> 
>  I am pleased to be calling this vote for the source release of Apache
>  NiFi 1.15.0.
> 
>  The source zip, including signatures, digests, etc. can be found at:
>  https://repository.apache.org/content/repositories/orgapachenifi-1186
> 
>  The source being voted upon and the convenience binaries can be found
> at:
>  https://dist.apache.org/repos/dist/dev/nifi/nifi-1.15.0/
> 
>  A helpful reminder on how the release candidate verification process
> works:
> 
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> 
>  The Git tag is nifi-1.15.0-RC3
>  The Git commit ID is 7fdc07cccdc0e23d4986557a9314e36859704a3b
> 
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=7fdc07cccdc0e23d4986557a9314e36859704a3b
> 
>  Checksums of nifi-1.15.0-source-release.zip:
>  SHA256:
> 56fe317248941fdbc6216ec973e6ce898d0f682a54e2d063edbabf8542f5288a
>  SHA512:
> 63f10d9127cf1613c29bf2306be3d7a5b931b31304920706e0df5ea2fe87b58c410efed6ac37afc38d12c65e69f14aec7afb926000fc90cc13f15c738cd15c7f
> 
>  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
> 
>  234 issues were closed/resolved for this release:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12350382
> 
>  Release note highlights can be found here:
> 
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.15.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.15.0
>  [ ] +0 no opinion
>  [ ] -1 Do not release this package because...
> >>>
>
>

Re: [ANNOUNCE] New NiFi PMC Member Marton Szasz

[Tony Kurc]

congratulations!

On Thu, Jun 24, 2021 at 6:23 PM Joe Witt  wrote:

> Congrats and thanks Marton
>
> On Thu, Jun 24, 2021 at 3:10 PM Otto Fowler 
> wrote:
>
> > Congratulations!
> >
> >
> >
> >
> > From: Arpad Boda  
> > Reply: dev@nifi.apache.org  
> > Date: June 24, 2021 at 15:01:31
> > To: NiFi Developers List  
> > Subject:  [ANNOUNCE] New NiFi PMC Member Marton Szasz
> >
> > On behalf of the Apache NiFI PMC, I am very pleased to announce that
> Marton
> > has accepted the PMC's invitation to join the Apache NiFi PMC. We greatly
> > appreciate the PR reviews and code contributions of Marton.
> >
> > Please join us in congratulating and welcoming Marton to the Apache NiFi
> > PMC.
> >
> > Congratulations Marton!
> >
>

Re: [VOTE] Release Apache NiFi MiNiFi C++ (RC2)

[Tony Kurc]

+1 (binding)

Went through the release helper, verified signatures and hashes, reviewed
NOTICE and LICENSE, and built without issues on Amazon Linux 2. Qualifier
on my +1 vote - I only tested the build with simple a very simple flow.


On Mon, Jun 7, 2021 at 3:50 PM Ferenc Gerlits  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> MiNiFi C++ 0.10.0.
>
> The source tarball, some binary builds, plus signatures and digests can be
> found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.10.0/
>
> The Git tag is minifi-cpp-0.10.0-RC2
> The Git commit ID is 60d5bc70b567fa7c6689f313a75be17fe7c94080
>
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=60d5bc70b567fa7c6689f313a75be17fe7c94080
>
> Checksums of nifi-minifi-cpp-0.10.0-source.tar.gz:
> SHA256: f7dc86ef6e35ea0d9c9c39891ea281a9851b1e6fc382b16d3a5931814f5ebc22
> SHA512:
>
> 484d3196d087e7c1acb5d703b827929edf0d8dae295878e1f79232ab8de4fd358f12fa223201c92e0cd9e0c59f2314da9001ac12eb91eabeda751e5d46c4f6b7
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/fgerlits.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 67 issues were closed/resolved for this release:
> https://issues.apache.org/jira/projects/MINIFICPP/versions/12349956
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.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-minifi-cpp-0.10.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi 1.13.1

[Tony Kurc]

+1 (binding)

Verified checksums and signature.
Build and ran simple flow on Amazon Linux 2, openjdk 1.8.0, maven 3.6.3.
Saw no issues with LICENSE or NOTICE

On Thu, Mar 11, 2021 at 11:29 AM Joe Witt  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.13.1.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1179
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.13.1/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.13.1-RC1
> The Git commit ID is acbc217cb7002d7489421f4d346b995a43b6ea01
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=acbc217cb7002d7489421f4d346b995a43b6ea01
>
> Checksums of nifi-1.13.1-source-release.zip:
> SHA256: 0a397df640e579720e26699e38a3738c5be05af01aad8aaeefc04eb58591faac
> SHA512:
>
> 7f8df759d4345ccd6e75c169bd0aab1b7f4f64bf5a8b11b45bc1d7c8163acd0035922dcdbef232392279f4ea0710d4a97c55d480281bfe1d50b6401295633d48
>
> 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
>
> 48 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12348700
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.13.1
>
> 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.13.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.9.0 (RC2)

[Tony Kurc]

+1 (binding)

Built on Amazon Linux 2 with the below build configuration (using
bootstrap.sh). Verified signature and checksum files. Reviewed LICENSE and
NOTICE, which looked good. Had some test failures, but appear to be
environmental rather than an issue. Ran a simple flow without issue.

The following features have been enabled:

 * STANDARD PROCESSORS, Provides standard processors
 * HTTP CURL, This enables RESTProtocol, InvokeHTTP, and the HTTPClient for
Site to Site
 * EXPRESSION LANGUAGE EXTENSIONS, This enables NiFi expression language
 * ROCKSDB REPOS, This Enables persistent provenance, flowfile, and content
repositories using RocksDB
 * ARCHIVE EXTENSIONS, This Enables libarchive functionality including
MergeContent, CompressContent, (Un)FocusArchiveEntry and ManipulateArchive.
 * GPS EXTENSIONS, Enables LibGPS Functionality and the GetGPS processor.
 * COAP EXTENSIONS, Enables LibCOAP Functionality.
 * PCAP EXTENSIONS, Enables libPCAP Functionality and the PacketCapture
processor.
 * RDKAFKA EXTENSIONS, This Enables librdkafka functionality including
PublishKafka
 * SCRIPTING EXTENSIONS, This enables scripting


On Tue, Feb 23, 2021 at 5:26 AM Marton Szasz  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi MiNiFi C++ 0.9.0
>
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.9.0/
>
> The release helper guide can be found at:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=173087303
>
> The Git tag is minifi-cpp-0.9.0-RC2
> The Git commit ID is ae746065319c89b6df23ef6a1bd6902306087cb8
>
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=ae746065319c89b6df23ef6a1bd6902306087cb8
>
> Checksums of nifi-minifi-cpp-0.9.0-source.tar.gz:
> SHA256: 519bbf273cc70874a8542d7e422302731c99f44e0aa6439d0e285fbcf4a6be74
> SHA512:
> 7ebc413f0bf85d25de4e50a2ca4d68925a362f2caa1f30c53a279591dca25d4866923c28418085b8485f73c36af737cf3549ed8990977ee55e4266f8b81b08bd
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/szaszm.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 200 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321520=12345444
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.9.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-minifi-cpp-0.9.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi 1.13.0 (rc4)

[Tony Kurc]

+1 (binding)

Built with java 8. Verified checksums and signature. Ran a really simple
flow without issue.

On Sat, Feb 13, 2021, 6:56 PM David Handermann 
wrote:

> +1 non-binding
>
> Verified release signatures and expected files.
> Verified build on Ubuntu 20.10 using Apache Maven 3.6.3 with Azul Zulu JDK
> 11.0.10 and AdoptOpenJDK 1.8.0_282.
> Verified absence of startup script shell warnings on Ubuntu 20.10.
> Verified service listening on localhost when using default nifi.properties.
> Configured and tested mutual TLS authentication on a standalone server with
> BCFKS key store and trust store.
>
> Regards,
> David Handermann
>
> On Fri, Feb 12, 2021 at 5:45 PM Muazma Zahid  wrote:
>
> > +1 (non-binding)
> >
> > - Ran build with OpenJDK 1.8.0_275 on Linux
> > - Deployed cluster on Azure and tested flows with Blob, ADLS, and
> CosmosDB
> > processors.
> >
> > Looks good to me.
> >
> > Thanks
> > Muazma
> >
> > On Fri, Feb 12, 2021 at 3:38 PM Sushil Kumar  wrote:
> >
> > > +1 (non-binding) Release this package as nifi-1.13.0
> > >
> > > Deployed this via helm chart(https://github.com/sushilkm/nifi-chart)
> on
> > > kubernetes.
> > > Thank you to all the contributors and reviewers.
> > >
> > > On Fri, Feb 12, 2021 at 2:13 PM Marc Parisi 
> wrote:
> > >
> > > > +1
> > > > - Verified sigs and hashes
> > > > - Built on PopOS w/ java 8 && 11
> > > > - Tested with basic flow sending data to various devices w/ Secured
> > > > transport
> > > > - Tested secured w/ secured nifi reg.
> > > >
> > > > Thanks,
> > > > Marc
> > > >
> > > > On Fri, Feb 12, 2021 at 2:56 PM Andrew Lim <
> andrewlim.apa...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > -Tested secure NiFi with secure NiFi Registry 0.8.0
> > > > > -Ran basic flows successfully
> > > > > -Tested basic versioned flow functionality
> > > > > -Reviewed and tested Core UI fixes and Documentation updates
> > > > >
> > > > > Drew
> > > > >
> > > > > > On Feb 10, 2021, at 11:37 PM, Joe Witt 
> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am pleased to be calling this vote for the source release of
> > Apache
> > > > > NiFi
> > > > > > 1.13.0.
> > > > > >
> > > > > > The source zip, including signatures, digests, etc. can be found
> > at:
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachenifi-1178
> > > > > >
> > > > > > The source being voted upon and the convenience binaries can be
> > found
> > > > at:
> > > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.13.0/
> > > > > >
> > > > > > A helpful reminder on how the release candidate verification
> > process
> > > > > works:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > > > > >
> > > > > > The Git tag is nifi-1.13.0-RC4
> > > > > > The Git commit ID is 3bc6a122091214b33eee17a270163d7ca26e2a0c
> > > > > >
> > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=3bc6a122091214b33eee17a270163d7ca26e2a0c
> > > > > >
> > > > > > Checksums of nifi-1.13.0-source-release.zip:
> > > > > > SHA256:
> > > > 95efe5db38e973c9f4062a7b2c95fdc5dad31d7c5e1d36ce1776b9b227c89b9c
> > > > > > SHA512:
> > > > > >
> > > > >
> > > >
> > >
> >
> d7dd9e851341ebd605784142a7861935f6f814bc612499013456a15713bc9119e426df8f26445c260bdb25cbfc21822cf0d44985bf372a065c9d8597953a3c4a
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > 260 issues were closed/resolved for this release:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12348700
> > > > > >
> > > > > > Release note highlights can be found here:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.13.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.13.0
> > > > > > [ ] +0 no opinion
> > > > > > [ ] -1 Do not release this package because...
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [discuss] we need to enable secure by default...

[Tony Kurc]

Joe,
In addition to your suggestions, were you thinking of making this processor
disabled by default as well?

Tony


On Tue, Feb 9, 2021, 11:04 PM Joe Witt  wrote:

> Team
>
> While secure by default may not be practical perhaps ‘not blatantly wide
> open’ by default should be adopted.
>
> I think we should consider killing support for http entirely and support
> only https.  We should consider auto generating a user and password and
> possibly server cert if nothing is configured and log the generated user
> and password.   Sure it could still be configured to be non secure but that
> would truly be an admins fault.  Now its just ‘on’
>
> This tweet is a great example of why
>
> https://twitter.com/_escctrl_/status/1359280656174510081?s=21
>
>
> Who agrees?  Who disagrees?   Please share ideas.
>
> Thanks
>

Re: [VOTE] Release Apache NiFi 1.12.1 (rc2)

[Tony Kurc]

+1 (binding)

Verified signature and hashes. Built without issue on ubuntu 18.04 x86_64
with openjdk11. Saw no issues with LICENSE or NOTICE.

Tony

On Wed, Sep 23, 2020, 6:10 PM Joe Witt  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.12.1.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1170
>
> The source being voted upon and the convenience binaries can be found at:
> https://dist.apache.org/repos/dist/dev/nifi/nifi-1.12.1/
>
> A helpful reminder on how the release candidate verification process works:
>
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
>
> The Git tag is nifi-1.12.1-RC2
> The Git commit ID is accfaa3034fa5c3ef55d6402ac31e500247100f9
>
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=accfaa3034fa5c3ef55d6402ac31e500247100f9
>
> Checksums of nifi-1.12.1-source-release.zip:
> SHA256: 7735c632c6795bb0d299631454bd81006db33d51192cacc1404a5c9779607802
> SHA512:
>
> e7f06afc7617df7e3325bce8e34d1d78c4d130c40135661e59ae0eabef50df888759a125dae3ab9556fc940d621c695a50e674ebad8c3066716bfb5fbd27c1c4
>
> 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
>
> 39 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12348757
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.12.1
>
> 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.12.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi 1.12.1

[Tony Kurc]

+1 (binding)

Built with openjdk 1.8, reviewed license,notice, and checked signature and
hashes.

On Fri, Sep 11, 2020 at 9:25 AM Kotaro Terada  wrote:

> +1 (non-binding)
>
> Verified signatures and hashes.
> Built packages with OpenJDK 1.8 and OpenJDK 11.
> Set up a secure 3-node cluster.
> Confirmed that the multiple SAN issue is resolved.
>
> Thanks,
> Kotaro
>
>
> On Fri, Sep 11, 2020 at 12:00 PM Chad Zobrisky 
> wrote:
>
> > +1 (non-binding)
> >
> > - Verified checksums, signatures
> > - Licenses + README looks good
> > - built in wsl using java 8
> > - ran using docker image secured with a certificate that had multiple
> SANS
> > and started up fine
> >
> > Chad
> >
> > On Thu, Sep 10, 2020 at 4:25 PM Peter Turcsanyi 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > - verified checksums and signatures
> > > - built source (empty local maven repo, AdoptOpenJDK 1.8.0_265 on
> Ubuntu
> > > 18.04.5), start up the binary
> > > - untar and ran the convenience binary too
> > > - tested some simple flows, including NIFI-7760 (fixed regression in
> > > UnpackContent)
> > >
> > > Peter
> > >
> > > On Thu, Sep 10, 2020 at 2:31 AM Joey Frazee  > > .invalid>
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > > Verified checksums and signatures
> > > > Ran full build with contrib check on Linux and Zulu OpenJDK 11.0.7
> > > > Tested TLS toolkit and secure cluster with multiple SANs
> > > >
> > > > -joey
> > > > On Sep 9, 2020, 8:51 AM -0700, Kevin Doran ,
> wrote:
> > > > > +1 (binding)
> > > > >
> > > > > - Checked hashes/sigs
> > > > > - L is present
> > > > > - Built from source and built docker images from resulting
> artifacts
> > > > > - Ran a docker compose environment with NiFi Registry 0.7.0 and
> NiFi
> > > > 1.12.1 RC1
> > > > > - Tested flow authoring and Registry integration in the test
> > > environment
> > > > >
> > > > > One thing to note is that running the docker profile from the
> > > > decompressed source distribution still results in some build errors
> due
> > > to
> > > > shell scripts we use for our docker container tests not being
> > executable.
> > > > At some point we should look into improving our release process to
> try
> > to
> > > > preserve those permissions, our making our build plugins robust
> enough
> > > that
> > > > those permissions are not required at build time.
> > > > >
> > > > > Kevin
> > > > >
> > > > > > On Sep 9, 2020, at 10:48, Bryan Bende  wrote:
> > > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > Ran through the release helper and everything looks good, used
> > 1.12.1
> > > > > > toolkit to generate certs for a secure instance.
> > > > > >
> > > > > > On Tue, Sep 8, 2020 at 11:36 PM Andrew Lim <
> > > andrewlim.apa...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > -Ran full clean install on OS X (Catalina 10.15.2)
> > > > > > > -Tested secure NiFi with secure NiFi Registry 0.7.0
> > > > > > > -Ran basic flows successfully; tested basic versioned flow
> > > > functionality
> > > > > > > -Reviewed documentation updates
> > > > > > >
> > > > > > > Drew
> > > > > > >
> > > > > > > > On Sep 8, 2020, at 12:59 PM, Joe Witt 
> > > wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I am pleased to be calling this vote for the source release
> of
> > > > Apache
> > > > > > > NiFi
> > > > > > > > 1.12.1.
> > > > > > > >
> > > > > > > > The source zip, including signatures, digests, etc. can be
> > found
> > > > at:
> > > > > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapachenifi-1167
> > > > > > > >
> > > > > > > > The source being voted upon and the convenience binaries can
> be
> > > > found at:
> > > > > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.12.1/
> > > > > > > >
> > > > > > > > A helpful reminder on how the release candidate verification
> > > > process
> > > > > > > works:
> > > > > > > >
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > > > > > > >
> > > > > > > > The Git tag is nifi-1.12.1-RC1
> > > > > > > > The Git commit ID is e8f708b3945183b7ab1b356c00d0fcbd929d6163
> > > > > > > >
> > > > > > >
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=e8f708b3945183b7ab1b356c00d0fcbd929d6163
> > > > > > > >
> > > > > > > > Checksums of nifi-1.12.1-source-release.zip:
> > > > > > > > SHA256:
> > > > 6fa7e4389ff33957133292e9749876affe1258e6f30d4e60b53e8c2d01d032cb
> > > > > > > > SHA512:
> > > > > > > >
> > > > > > >
> > > >
> > >
> >
> fee615ee885b05a290a4d6c7399ecf0b70a93cc1d5d9b019c7840ceb89d3279a540da4de75765c589c301fff751e62c9e15cc33d078b5fad03bbbd28e74f8ea9
> > > > > > > >
> > > > > > > > Release artifacts are signed with the following key:
> > > > > > > > https://people.apache.org/keys/committer/joewitt.asc
> > > > > > > >
> > > > > > > > KEYS file available here:
> > > > > > > > 

Re: [RESULT][VOTE] Release Apache NiFi 1.12.0

[Tony Kurc]

yeah!!

On Tue, Aug 18, 2020 at 4:50 PM Mark Payne  wrote:

> Awesome! Thanks for doing all the work to get the release out, Joe!
>
> -Mark
>
> Sent from my iPhone
>
> > On Aug 18, 2020, at 4:48 PM, Joe Witt  wrote:
> >
> > Apache NiFi Community,
> >
> > I am pleased to announce that the 1.12.0 release of Apache NiFi passes
> with
> >11 +1 (binding) votes
> >9 +1 (non-binding) votes
> >0 0 votes
> >0 -1 votes
> >
> > Thanks to all who helped make this release possible. Pretty awesome turn
> > out on the vote so thank you!
> >
> > Here is the PMC vote thread:
> >
> https://lists.apache.org/thread.html/r42081bf5f6a394be91381dedb477c6ed666b1dc2251dbd0b59b6b252%40%3Cdev.nifi.apache.org%3E
> >
> >
> >> On Tue, Aug 18, 2020 at 1:44 PM Joe Witt  wrote:
> >>
> >> +1 binding
> >>
> >>> On Tue, Aug 18, 2020 at 11:39 AM Marton Szasz 
> wrote:
> >>>
> >>> +1 (non-binding)
> >>>
> >>> Signature, hashes, commit ID, README, LICENSE and NOTICE all look OK.
> >>> Built
> >>> and tested with Java 8, ran a simple MiNiFi C++ HTTP S2S -> NiFi flow.
> >>>
> >>> Thanks,
> >>> Marton
> >>>
> >>>
>  On Mon, 17 Aug 2020 at 15:35,  wrote:
> >>>
>  +1 (non-binding)
> 
>  Compile and ran with Amazon Correttto Java 8 on OSX.  I had an issue
>  getting site-to-site to work between NiFi 1.11.4 and NiFi 1.12.0 in
> RAW
>  mode (non-secure) and had to switch to using HTTP.  The message on the
>  Remote Process Group read “Remote instance is not configured to allow
> >>> RAW
>  Site-to-site communication at this time".  Are new configurations
> >>> required
>  to transmit Iva Site-to-site in RAW mode?  I didn’t see anything in
> the
>  docs or online.  Note that I was running both versions on the same
> >>> computer
>  and modified the one instance with the following properties.
> 
>  nifi.web.http.port=8081
>  nifi.remote.input.socket.port=9991
> 
>  Rick
> 
>  --
>  Richard St. John, PhD
>  Asymmetrik
>  AGILITY | EXPERIENCE | RESULTS
>  308 Sentinel Drive, Suite 400
>  Annapolis Junction, MD 20701
>  On Aug 16, 2020, 11:03 PM -0400, Chad Zobrisky ,
>  wrote:
> > +1 (non-binding)
> >
> > Ran through the release helper, everything looks good.
> > Full build on java8 in wsl, ubuntu.
> > Verified basic functionality in single node and 5 cluster docker
> > configuration.
> >
> > - Chad
> >
> >
> > On Sat, Aug 15, 2020 at 7:26 AM Marc Parisi 
> >>> wrote:
> >
> >> +1 (binding )
> >>
> >> Ran through helper guide with clean build env . Ran flows that
> >>> ingest
>  and
> >> query Apache hbase and accumulo from a 10 VM secured cluster in my
>  local
> >> environment with jdk11.
> >>
> >> Thanks,
> >> Marc
> >>
> >>
> >> On Sat, Aug 15, 2020, 7:11 AM Kotaro Terada 
>  wrote:
> >>
> >>> +1 (non-binding)
> >>>
> >>> Verified signatures and hashes.
> >>> Built an RPM package with OpenJDK 11.0.8 on CentOS 7.8.
> >>> Set up a 3-node cluster.
> >>> Tested several flows.
> >>>
> >>> Thanks,
> >>> Kotaro
> >>>
> >>>
> >>> On Sat, Aug 15, 2020 at 5:09 PM Joey Frazee <
> >>> joey.fra...@icloud.com
> >>> .invalid>
> >>> wrote:
> >>>
>  +1 (non-binding)
> 
>  Verified commit id, checksums, and signatures
>  Successfully built and ran tests on Linux with Java 1.8.0_252
> >>> and
>  Java
>  11.0.7 2020-04-14 and on macOS with Java 11.0.6 2020-01-14 LTS
>  Ran data flows on standalone and cluster
>  Verified JMS improvements, InvokeHTTP changes, and Azure
>  integration in
>  commercial and gov regions
> 
>  -joey
>  On Aug 14, 2020, 1:31 PM -0700, Robert Fellows <
>  rob.fell...@gmail.com
> >>> ,
>  wrote:
> > + 1 (non-binding)
> >
> > Ran through the release helper, verified checksums and sigs.
> > Full build with java 11
> > Verified basic app usage/functionality.
> >
> >
> >
> > On Fri, Aug 14, 2020 at 4:04 PM Muazma Zahid <
> >>> mua...@gmail.com>
> >> wrote:
> >
> >> +1 (non-binding)
> >> Ran through the release helper. Deployed a 10 node cluster
> >>> on
>  Azure
> >>> and
> >> verified the functionality of new ADLS processors with a
>  standard
> >>> flow.
> >> Looks good to me.
> >>
> >> Thanks,
> >> Muazma
> >>
> >> On Fri, Aug 14, 2020 at 12:45 PM Andrew Lim <
>  andrewlim.apa...@gmail.com>
> >> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> -Ran full clean install on OS X (Catalina 10.15.2)
> >>> -Tested secure NiFi with secure NiFi Registry 0.7.0
> >>> -Ran basic flows successfully; tested basic versioned flow
>  

Re: [VOTE] Release Apache NiFi 1.12.0

[Tony Kurc]

+1 (binding)

Verified checksums and signature. No issues building or running. Did not
see any issues with LICENSE or NOTICE.

On Mon, Aug 17, 2020, 5:07 AM Pierre Villard 
wrote:

> +1 (binding)
>
> Went through the usual steps. Deployed a secured cluster on GCP and tried a
> few flows. Confirmed some fixes, tested the ScriptedTransformRecord
> processor, and the new flowfile concurrency features.
>
> Thanks all for this great release, a lot of really good stuff!
> Thanks Joe for taking care of the release management!
>
> Le lun. 17 août 2020 à 05:03, Chad Zobrisky  a écrit
> :
>
> > +1 (non-binding)
> >
> > Ran through the release helper, everything looks good.
> > Full build on java8 in wsl, ubuntu.
> > Verified basic functionality in single node and 5 cluster docker
> > configuration.
> >
> > - Chad
> >
> >
> > On Sat, Aug 15, 2020 at 7:26 AM Marc Parisi  wrote:
> >
> > > +1 (binding )
> > >
> > > Ran through helper guide with clean build env . Ran flows that ingest
> and
> > > query Apache hbase and accumulo from a 10 VM secured cluster in my
> local
> > > environment with jdk11.
> > >
> > > Thanks,
> > > Marc
> > >
> > >
> > > On Sat, Aug 15, 2020, 7:11 AM Kotaro Terada 
> wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Verified signatures and hashes.
> > > > Built an RPM package with OpenJDK 11.0.8 on CentOS 7.8.
> > > > Set up a 3-node cluster.
> > > > Tested several flows.
> > > >
> > > > Thanks,
> > > > Kotaro
> > > >
> > > >
> > > > On Sat, Aug 15, 2020 at 5:09 PM Joey Frazee  > > > .invalid>
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Verified commit id, checksums, and signatures
> > > > > Successfully built and ran tests on Linux with Java 1.8.0_252 and
> > Java
> > > > > 11.0.7 2020-04-14 and on macOS with Java 11.0.6 2020-01-14 LTS
> > > > > Ran data flows on standalone and cluster
> > > > > Verified JMS improvements, InvokeHTTP changes, and Azure
> integration
> > in
> > > > > commercial and gov regions
> > > > >
> > > > > -joey
> > > > > On Aug 14, 2020, 1:31 PM -0700, Robert Fellows <
> > rob.fell...@gmail.com
> > > >,
> > > > > wrote:
> > > > > > + 1 (non-binding)
> > > > > >
> > > > > > Ran through the release helper, verified checksums and sigs.
> > > > > > Full build with java 11
> > > > > > Verified basic app usage/functionality.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 14, 2020 at 4:04 PM Muazma Zahid 
> > > wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > > Ran through the release helper. Deployed a 10 node cluster on
> > Azure
> > > > and
> > > > > > > verified the functionality of new ADLS processors with a
> standard
> > > > flow.
> > > > > > > Looks good to me.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Muazma
> > > > > > >
> > > > > > > On Fri, Aug 14, 2020 at 12:45 PM Andrew Lim <
> > > > > andrewlim.apa...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 (binding)
> > > > > > > >
> > > > > > > > -Ran full clean install on OS X (Catalina 10.15.2)
> > > > > > > > -Tested secure NiFi with secure NiFi Registry 0.7.0
> > > > > > > > -Ran basic flows successfully; tested basic versioned flow
> > > > > functionality
> > > > > > > > -Reviewed documentation updates. Lots of a great additions in
> > > this
> > > > > > > release!
> > > > > > > > -Reviewed core UI fixes and improvements. Verified that
> > > controller
> > > > > > > > services are searchable [1], but filed a Jira for the
> > navigation
> > > to
> > > > > the
> > > > > > > > controller service being broken [2].
> > > > > > > >
> > > > > > > > Drew
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/NIFI-5925 <
> > > > > > > > https://issues.apache.org/jira/browse/NIFI-5925>
> > > > > > > > [2] https://issues.apache.org/jira/browse/NIFI-7742 <
> > > > > > > > https://issues.apache.org/jira/browse/NIFI-7742>
> > > > > > > >
> > > > > > > > > On Aug 13, 2020, at 4:31 PM, Joe Witt 
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > I am pleased to be calling this vote for the source release
> > of
> > > > > Apache
> > > > > > > > NiFi
> > > > > > > > > 1.12.0.
> > > > > > > > >
> > > > > > > > > The source zip, including signatures, digests, etc. can be
> > > found
> > > > > at:
> > > > > > > > >
> > > > >
> > https://repository.apache.org/content/repositories/orgapachenifi-1165
> > > > > > > > >
> > > > > > > > > The source being voted upon and the convenience binaries
> can
> > be
> > > > > found
> > > > > > > at:
> > > > > > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.12.0/
> > > > > > > > >
> > > > > > > > > A helpful reminder on how the release candidate
> verification
> > > > > process
> > > > > > > > works:
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > > > > > > > >
> > > > > > > > > The Git tag is nifi-1.12.0-RC1
> > > > 

Re: [ANNOUNCE] New Apache NiFi Committer Marton Szasz

[Tony Kurc]

Congrats Marton!

On Mon, Aug 3, 2020 at 4:02 AM Arpad Boda  wrote:

> Apache NiFi community,
>
> On behalf of the Apache NiFI PMC, I am very pleased to announce that Marton
> has accepted the PMC's invitation to become a committer on the Apache NiFi
> project. We greatly appreciate all of Marton's hard work and generous
> contributions to the project. We look forward to continued involvement in
> the project.
>
> Marton had more than 100 contributions to MiNiFi C++ this year in various
> areas: from Windows-specific memory leaks to nice new features and a lot of
> code reviews. He also showed active presence on the mailing list helping
> out the community.
>
> Welcome and congratulations!
>

Re: [VOTE] Release Apache NiFi Registry 0.7.0

[Tony Kurc]

+1 (binding)

Built on an ubuntu 16.04 x64 w/openjdk 11 without issues. Verified
signatures and hashes. Saw no issues with LICENSE or NOTICE.

Tony

On Fri, Jul 17, 2020 at 10:10 PM Marc Parisi  wrote:

> +1 binding
>
> Verified sigs and hashes
>
> Built and run on Linux LXC (Java 11) w/ Secured Apache NiFi built and run
> in the same container. All looked good
>
> Perused L and it looked good.
>
> Thanks,
> Marc
>
> On Fri, Jul 17, 2020 at 5:48 PM Peter Turcsanyi 
> wrote:
>
> > +1 (non-binding)
> >
> > - verified signatures and checksums
> > - built with Java 8 (empty local maven repo, OS: Ubuntu 18)
> > - run NiFi Registry and connected to it from NiFi 1.11.4 (unsecure),
> > performed some tests
> > - download the convenience binary and tested a few things on it too
> >
> > Thanks,
> > Peter
> >
> > On Fri, Jul 17, 2020 at 7:20 PM Marton Szasz  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Followed the verification guide, migrated a test deployment using
> > > GitFlowPersistenceProvider from 0.6.0, then tested MiNiFi C++ C2 flow
> > > update using the new registry version.
> > >
> > > Thanks,
> > > Marton
> > >
> > > On Fri, 17 Jul 2020 at 18:36, Mark Payne  wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > Verified full build with contrib check, deployed and performed some
> > > tests,
> > > > verifying that the FlowFiles concurrency and outbound policy was
> > properly
> > > > stored and retrieved.
> > > >
> > > > Thanks
> > > > -Mark
> > > >
> > > >
> > > > > On Jul 17, 2020, at 11:55 AM, Pierre Villard <
> > > > pierre.villard...@gmail.com> wrote:
> > > > >
> > > > > +1 (binding)
> > > > >
> > > > > * went through the usual release verification steps (signatures,
> > build,
> > > > > contrib check, licenses)
> > > > > * deployed a local NR 0.7.0 instance with a single local NiFi
> > > > > 1.12.0-SNAPSHOT (non secure)
> > > > >
> > > > > Thanks Bryan for taking care of this!
> > > > >
> > > > > Le ven. 17 juil. 2020 à 17:46, Matt Burgess 
> a
> > > > écrit :
> > > > >
> > > > >> +1 (binding), verified hashes and commit ID, tested a few things
> on
> > an
> > > > >> unsecured instance. Thanks for RM'ing Bryan!
> > > > >>
> > > > >> On Wed, Jul 15, 2020 at 11:32 AM Bryan Bende 
> > > wrote:
> > > > >>>
> > > > >>> Hello,
> > > > >>>
> > > > >>> I am pleased to be calling this vote for the source release of
> > Apache
> > > > >> NiFi
> > > > >>> Registry 0.7.0.
> > > > >>>
> > > > >>> The source zip, including signatures, digests, etc. can be found
> > at:
> > > > >>>
> > > https://repository.apache.org/content/repositories/orgapachenifi-1161
> > > > >>>
> > > > >>> The source being voted upon and the convenience binaries can be
> > found
> > > > at:
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.7.0/
> > > > >>>
> > > > >>> A helpful reminder on how the release candidate verification
> > process
> > > > >> works:
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > > > >>>
> > > > >>> The Git tag is nifi-registry-0.7.0-RC1
> > > > >>> The Git commit ID is c8f26039712354b94c4d458b7ea491316c6facac
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=nifi-registry.git;a=commit;h=c8f26039712354b94c4d458b7ea491316c6facac
> > > > >>>
> > > > >>> Checksums of nifi-registry-0.7.0-source-release.zip:
> > > > >>> SHA256:
> > > > acc6b21444d229d78b8a604750231e1c7e80495c9cccfb59ec043ebe952fd2a8
> > > > >>> SHA512:
> > > > >>>
> > > > >>
> > > >
> > >
> >
> 428839e0c861095547e328fcfda42cb3f2a87c0b03f7205d6878f8b7267975fe2ad051d4b5f980cac8f47a249c8ee21686c8d909f275454e25d8a654099bd683
> > > > >>>
> > > > >>> 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
> > > > >>>
> > > > >>> 19 issues were closed/resolved for this release:
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320920=12346077
> > > > >>>
> > > > >>> Release note highlights can be found here:
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFIREG/Release+Notes#ReleaseNotes-NiFiRegistry0.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-registry-0.7.0
> > > > >>> [ ] +0 no opinion
> > > > >>> [ ] -1 Do not release this package because...
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc]

After a quick review, in nifi, I wasn't able to find references to the
properties Joe mentioned, but I did use crude recursive greps to look. A
majority of the blacklist references were in wali in method names and log
messages. Picking a more useful term in wali would probably make sense.
I'll make a jira, but we'd need to be a bit more deliberate about when that
change could happen, no? Long story short, since assumptions were maybe a
bit off (i.e. not an additive change), I think a later release may make
sense.

There was a blacklist property in nifi-cpp. I'll make a jira and work on a
pr for that.

Most prevalent in my grep analysis related to master/slave were carrying
over terms from dependencies (e.g. MySQL, zookeeper, or third-party libs in
nifi-cpp) and "master key" crypt related stuff.

On Mon, Jul 6, 2020, 6:02 PM Tony Kurc  wrote:

> Mike,
> I did a quick check to see if anyone had done a jira or pr for #2, so I'll
> take a stab at doing that today.
>
> Tony
>
> On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen 
> wrote:
>
>> Didn't see any commits or PRs for any of these yet. Do we want to consider
>> these blockers for 1.12 or hold off until a post 1.12 release?
>>
>> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt  wrote:
>>
>> > Not that I'm aware of.  All this so far just looks really easy to deal
>> > with.
>> >
>> > On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen 
>> > wrote:
>> >
>> > > Out of curiosity... are there any cases you've found where we might
>> have
>> > a
>> > > term misalignment with what another product calls them? Like we might
>> > have
>> > > primary/replica and the supported system uses master/slave?
>> > >
>> > > On Mon, Jun 22, 2020 at 11:32 AM Joe Witt  wrote:
>> > >
>> > > > ...additional note after reviewing the presence of
>> > 'whitelist/blacklist'
>> > > I
>> > > > remain of the view what we need to do here is easy.  There is
>> minimal
>> > API
>> > > > impact and it appears to be just the nifi.properties file for a
>> > property.
>> > > > Other code changes do not appear to be API related and seem fair
>> game
>> > > now.
>> > > > We can easily support the old naming and create a different property
>> > name
>> > > > for the properties file case.  We dont need to wait for any major
>> > release
>> > > > as far as I can tell
>> > > >
>> > > > Thanks
>> > > >
>> > > > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen <
>> mikerthom...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > I think just shooting for #1 right away makes sense, but #2 will
>> need
>> > > to
>> > > > be
>> > > > > done as part of a major release. I think we go all-in to be
>> > consistent
>> > > on
>> > > > > allow/block vs white/black and similar changes that are needed. We
>> > > should
>> > > > > also avoid things like the proposal to use "allowlist/denylist"
>> that
>> > > > other
>> > > > > teams are debating since that is just a pointless spawning of
>> > > neologisms
>> > > > > for the sake of creating them. The best approach is to use clear,
>> > > concise
>> > > > > language that is preferably as limited on jargon as possible, and
>> I
>> > > feel
>> > > > > like those teams are missing the mark on that. If we do find
>> language
>> > > > that
>> > > > > needs to be changed in descriptor name fields, I think it would
>> also
>> > > > > prevent any problems by making part of the messaging being that
>> those
>> > > > > changes are non-negotiable as they represent real potential
>> breakage
>> > to
>> > > > > users. I think most folks would be fine with that, but it might
>> need
>> > to
>> > > > be
>> > > > > spelled out for some that there is a balance that has to be
>> > maintained
>> > > > > until a proper transition can take place.
>> > > > >
>> > > > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc 
>> wrote:
>> > > > >
>> > > > > > This discussion has died down quite a bit. I got the impression
>> > there
>> > > > was
>> &

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc]

Mike,
I did a quick check to see if anyone had done a jira or pr for #2, so I'll
take a stab at doing that today.

Tony

On Thu, Jul 2, 2020 at 10:27 PM Mike Thomsen  wrote:

> Didn't see any commits or PRs for any of these yet. Do we want to consider
> these blockers for 1.12 or hold off until a post 1.12 release?
>
> On Mon, Jun 22, 2020 at 12:48 PM Joe Witt  wrote:
>
> > Not that I'm aware of.  All this so far just looks really easy to deal
> > with.
> >
> > On Mon, Jun 22, 2020 at 9:46 AM Mike Thomsen 
> > wrote:
> >
> > > Out of curiosity... are there any cases you've found where we might
> have
> > a
> > > term misalignment with what another product calls them? Like we might
> > have
> > > primary/replica and the supported system uses master/slave?
> > >
> > > On Mon, Jun 22, 2020 at 11:32 AM Joe Witt  wrote:
> > >
> > > > ...additional note after reviewing the presence of
> > 'whitelist/blacklist'
> > > I
> > > > remain of the view what we need to do here is easy.  There is minimal
> > API
> > > > impact and it appears to be just the nifi.properties file for a
> > property.
> > > > Other code changes do not appear to be API related and seem fair game
> > > now.
> > > > We can easily support the old naming and create a different property
> > name
> > > > for the properties file case.  We dont need to wait for any major
> > release
> > > > as far as I can tell
> > > >
> > > > Thanks
> > > >
> > > > On Sat, Jun 20, 2020 at 4:47 PM Mike Thomsen  >
> > > > wrote:
> > > >
> > > > > I think just shooting for #1 right away makes sense, but #2 will
> need
> > > to
> > > > be
> > > > > done as part of a major release. I think we go all-in to be
> > consistent
> > > on
> > > > > allow/block vs white/black and similar changes that are needed. We
> > > should
> > > > > also avoid things like the proposal to use "allowlist/denylist"
> that
> > > > other
> > > > > teams are debating since that is just a pointless spawning of
> > > neologisms
> > > > > for the sake of creating them. The best approach is to use clear,
> > > concise
> > > > > language that is preferably as limited on jargon as possible, and I
> > > feel
> > > > > like those teams are missing the mark on that. If we do find
> language
> > > > that
> > > > > needs to be changed in descriptor name fields, I think it would
> also
> > > > > prevent any problems by making part of the messaging being that
> those
> > > > > changes are non-negotiable as they represent real potential
> breakage
> > to
> > > > > users. I think most folks would be fine with that, but it might
> need
> > to
> > > > be
> > > > > spelled out for some that there is a balance that has to be
> > maintained
> > > > > until a proper transition can take place.
> > > > >
> > > > > On Sat, Jun 20, 2020 at 6:23 PM Tony Kurc 
> wrote:
> > > > >
> > > > > > This discussion has died down quite a bit. I got the impression
> > there
> > > > was
> > > > > > at least majority support, although not consensus, for Joe's two
> > > > > proposals
> > > > > > [1].
> > > > > >
> > > > > > #1 ( s/master/main/ ) is probably the most straightforward -
> change
> > > > > > developer docs and make the necessary repository changes. Can be
> > done
> > > > > > seemingly independent of software releases. Is it time for jiras
> on
> > > > that?
> > > > > > My sense is that 'main' appears to be a common term that projects
> > > > appear
> > > > > to
> > > > > > be gravitating to, but that discussion still abounds. This
> comment
> > > [2]
> > > > on
> > > > > > the git project's mailing list hurt my head quite a bit, but
> > > definitely
> > > > > > reinforced that main makes a whole lot more sense than master, as
> > > Andy
> > > > > > pointed out [3].
> > > > > >
> > > > > > #2 is a bit less straightforward, going to require a code change
> > and
> > > > > figure
> > > > >

Re: AWS S3

[Tony Kurc]

I did testing of a set of s3 processors a long while ago without AWS using
https://s3ninja.net/

On Fri, Jun 26, 2020 at 2:17 PM younggyu Chun 
wrote:

> Hi all,
>
> I am working https://issues.apache.org/jira/browse/NIFI-7579 but I think
> we
> need an AWS S3 account to test.
>
> thanks,
> younggyu
>

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc]

d change "Master Branch" to "Main Branch".
> > > > But I also think that we shouldn't just make quick changes because
> it's
> > > > opportune and hastily change a few words.
> > > >
> > > > An example: We could change Master/Slave to Leader/Follower. This may
> > be
> > > > a perfect choice for most people in the world.
> > > > In German Leader is the English word for "Führer". And it is
> precisely
> > > > this word that we in Germany do not actually want to use for it.
> > > >
> > > > What I mean is that every country and every group (e.g. religion
> etc.)
> > > > has its own history and certain words or phrases are just not a
> perfect
> > > > choice.
> > > > We should try to go the ethically correct way worldwide.
> > > >
> > > > This concerns the adaptation of current words and phrases with a view
> > to
> > > > all: in English, Indian, Chinese, German etc. but also for indigenous
> > > > peoples, different religions etc.
> > > > And cultural differences should also be taken into account.
> > > >
> > > > What I would wish for:
> > > > Apache.org should set up an "Ethics Board". A group of people of
> > > > different genders, all colors, religions and from different countries
> > > > and cultures all over our world.
> > > > This Ethics Board should find good and for no one discriminating
> words
> > > > or phrases for all the areas that stand out today as offensive.
> > > >
> > > > And it would be nice if not only computer scientists participated,
> but
> > > > also ethicists, philosophers, engineers, various religious people,
> > > > chemists, biologists, physicists, sociologists, etc.
> > > >
> > > > And this Council should set binding targets for all projects.
> > > >
> > > > Am 18.06.2020 um 09:36 schrieb Pierre Villard:
> > > > > > In my perspective this should be an issue for the entire
> community.
> > > > Being
> > > > > > able to identify an issue that directly affects another person
> but
> > not
> > > > > > one’s self is the definition of privilege. If I can look at how
> > the use
> > > > of
> > > > > > these words in someone’s daily life or career impacts them
> > negatively,
> > > > > when
> > > > > > the change would not harm me at all, I see that as a failure on
> my
> > > > part. I
> > > > > > understand the desire to hear from the silent majority, but
> active
> > > > > > participation and discussion on the mailing list is the exact
> > measure
> > > > > > described by the Apache process for participation in the
> community.
> > > > Those
> > > > > > who speak here are the ones who will have a voice.
> > > > > I could not agree more with the above.
> > > > >
> > > > > Le jeu. 18 juin 2020 à 04:29, Tony Kurc  a écrit
> :
> > > > >
> > > > > > I suppose I was a bit remiss in not unwinding and/or summarizing
> > some of
> > > > > > what was in that yetus thread to prime the discussion, but a some
> > of
> > > > what
> > > > > > Andy is mentioning is expanded on a bit in this ietf document
> [1],
> > > > which is
> > > > > > linked in one of the articles.
> > > > > >
> > > > > > 1. https://tools.ietf.org/id/draft-knodel-terminology-00.html
> > > > > >
> > > > > >
> > > > > > On Wed, Jun 17, 2020, 10:02 PM Andy LoPresto <
> alopre...@apache.org
> > >
> > > > wrote:
> > > > > >
> > > > > > > Hi Edward, thanks for sharing your thoughts. I’ll reply inline.
> > > > > > >
> > > > > > > > - Some of the terms proposed are not industry standard and
> may
> > > > > > > potentially
> > > > > > > > cause significant issue for non-english speakers.
> > > > > > > I actually believe making these changes will _improve_ the
> > clarity for
> > > > > > > non-english speakers. “Whitelist” and “blacklist” confer no
> > inherent
> > > > > > reason
> > > > > > > to mean allow and deny other than

Re: [DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc]

lopresto.apa...@gmail.com
> He/Him
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Jun 17, 2020, at 6:43 PM, Edward Armes 
> wrote:
> >
> > This is a difficult issue and causes no small amount of friction every
> > time. I'm personally against this for the following reassons:
> >
> > - Some of the terms proposed are not industry standard and may
> potentially
> > cause significant issue for non-english speakers.
> >
> > - For each change that is made can we guarantee that we will not lose
> > clarity of meaning, and then have revert the change down the line if the
> > change causes a drop in usage.
> >
> > - Of what percentage of people is this truly an issue for and what
> > percentage isn't. Any change that has the potential to cause a major
> split
> > in the community, there must be as close as possible to a majority, and
> not
> > just from those that are vocal and active on the mailing lists.
> > Disscustions on other groups are turning toxic, and in some cases are
> > potentially leading to the collapse of these projects where these changes
> > are being implemented with what appears to be without the agreement of a
> > signifficant chunk of the community.
> >
> > - From a personal perspective, I sit on the autism spectrum and have
> grown
> > up with people using words that are very offensive and have hurt me
> badly.
> > Instead of having these words as offensive and untouchable. Myself and
> > others have instead made these words our own and made them lose the
> > negative connotations they have. As such, I do find the current
> > disscustions deeply alarming and feels like they start to border into the
> > realm of censorship.
> >
> > - One final point (and potentially controversial), A good chunk of the
> > wording that is proposed to be changed. Is being done so on the
> > "modern"/"street" definition of these words and not the actual
> definition.
> > Language should change and evolve to introduce clarity, but right now
> does
> > this change improve the clarity across the engineering sector and I
> believe
> > it won't.
> >
> > Edward
> >
> >
> > On Thu, 18 Jun 2020, 01:11 Andy LoPresto,  wrote:
> >
> >> I am a proponent of making this change and also using allow/deny list,
> >> meddler-in-the-middle, etc.
> >>
> >> Here is a blog [1] with easy instructions for executing the change in
> git,
> >> although I don’t know if there is any Apache-integration specific
> changes
> >> we would also need.
> >>
> >> [1]
> >>
> https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx
> >>
> >> Andy LoPresto
> >> alopre...@apache.org
> >> alopresto.apa...@gmail.com
> >> He/Him
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >>> On Jun 17, 2020, at 3:06 PM, Joe Witt  wrote:
> >>>
> >>> I suspect it would be fairly easy to make this change.  We do, I think,
> >>> have whitelist/blacklist in there somewhere but im not sure how
> involved.
> >>>
> >>> On Wed, Jun 17, 2020 at 3:04 PM Tony Kurc  wrote:
> >>>
> >>>> All,
> >>>> I've seen the discussion started on other projects [1][2], so I wanted
> >> to
> >>>> kick off a discussion to determine whether this is something nifi
> could
> >>>> look at too. Allen Wittenauer's post to yetus captures the why and
> some
> >> of
> >>>> the how, so rather than copy and pasting, you can take a look at what
> >> he's
> >>>> done. Thoughts?
> >>>>
> >>>> Tony
> >>>>
> >>>> 1.
> >>>>
> >>>>
> >>
> https://lists.apache.org/thread.html/rd38afa9fb6c0dcd77d1a677f1152b7398b3bda93c9106b3393149d10%40%3Cdev.yetus.apache.org%3E
> >>>> 2.
> >>>>
> >>>>
> >>
> https://lists.apache.org/thread.html/r0825eec0c84296bdab7cf898a987f06355443241ca02b2aaa51d3ef9%40%3Cdev.accumulo.apache.org%3E
> >>>>
> >>
> >>
>
>

[DISCUSS] rename master branch, look through code for other related issues

[Tony Kurc]

All,
I've seen the discussion started on other projects [1][2], so I wanted to
kick off a discussion to determine whether this is something nifi could
look at too. Allen Wittenauer's post to yetus captures the why and some of
the how, so rather than copy and pasting, you can take a look at what he's
done. Thoughts?

Tony

1.
https://lists.apache.org/thread.html/rd38afa9fb6c0dcd77d1a677f1152b7398b3bda93c9106b3393149d10%40%3Cdev.yetus.apache.org%3E
2.
https://lists.apache.org/thread.html/r0825eec0c84296bdab7cf898a987f06355443241ca02b2aaa51d3ef9%40%3Cdev.accumulo.apache.org%3E

[ANNOUNCE] New NiFi PMC member Drew Lim

[Tony Kurc]

NiFi Community,

On behalf of the Apache NiFi PMC, I am pleased to announce that Drew Lim
has accepted the PMC's invitation to join the Apache NiFi PMC.

Drew has been doing an amazing job for several years making NiFi more
approachable and usable. He's contributed to almost every part of NiFi;
going over and beyond to improve documentation and usability.

Please join us in congratulating and welcoming Drew to the Apache NiFi PMC.

Congratulations Drew!

Tony

[ANNOUNCE] New NiFi PMC member Arpad Boda

[Tony Kurc]

NiFi Community,

On behalf of the Apache NiFi PMC, I am pleased to announce that Arpad Boda
has accepted the PMC's invitation to join the Apache NiFi PMC.

In addition to being a regular code contributor and engaged community
member with the project, (especially MiNiFi C++!) for quite some time,
Arpad has done the arduous task of being a release manager for both NiFi
Registry and MiNiFi C++, which is a challenging and detail oriented task.

Please join us in congratulating and welcoming Arpad to the Apache NiFi PMC.

Congratulations Arpad!

Tony

Re: [VOTE] Release Apache NiFi Registry 0.6.0

[Tony Kurc]

+1 (binding)

Ran through the helper, compiled no problem, ran without issue, and didn't
see issues with licenses.

On Thu, Apr 2, 2020 at 11:54 AM Arpad Boda  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi Registry nifi-registry-0.6.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1160
>
> The Git tag is nifi-registry-0.6.0-RC1
> The Git commit ID is ed5c9b3f2faa8b1cab18f157b7d3263dae289aae
>
> https://gitbox.apache.org/repos/asf?p=nifi-registry.git;a=commit;h=ed5c9b3f2faa8b1cab18f157b7d3263dae289aae
>
> Checksums of nifi-registry-0.6.0-source-release.zip:
> SHA256: 0ed06ef762588be0154207932d2d1ebd1266c45aed299d0fb170cbeabd4c6e2b
> SHA512:
>
> aa1f03c20902bf9cd94574e45cbd57526763ab135421e9d1df489cac7c487cb9c6d20ba3f6a74d7ae37b97a7de71d12edbc1c9fabf6d6b29f29397164011e097
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/aboda.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 40 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320920=12347009
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFIREG/Release+Notes#ReleaseNotes-NiFiRegistry0.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.
>
> Then please vote:
> [ ] +1 Release this package as nifi-registry-0.6.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: [VOTE] Release Apache NiFi 1.11.4

[Tony Kurc]

+1 (binding)

Ran through "helper" on ubuntu without issue.

On Fri, Mar 20, 2020 at 7:23 PM Matt Gilman  wrote:

> +1 (binding)
>
> Thanks for RMing Joe!
>
> On Fri, Mar 20, 2020 at 6:06 PM M Tien  wrote:
>
> > +1 (non-binding)
> >
> > - Verified checksums, signatures, and commit hash
> > - Ran build and all tests on OS X
> > - Deployed secure standalone instance
> > - Verified the fix was applied to use keystorePassword when keyPassword
> is
> > empty for nifi.properties, InvokeHTTP, ListenHTTP, and
> > HandleHTTPRequest/Response.
> >
> > Thanks,
> > M. Tien
> >
> > > On Mar 18, 2020, at 10:15 AM, Joe Witt  wrote:
> > >
> > > Hello,
> > >
> > > I am pleased to be calling this vote for the source release of Apache
> > NiFi
> > > 1.11.4.
> > >
> > > The source zip, including signatures, digests, etc. can be found at:
> > > https://repository.apache.org/content/repositories/orgapachenifi-1159
> > >
> > > The source being voted upon and the convenience binaries can be found
> at:
> > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.4/
> > >
> > > A helpful reminder on how the release candidate verification process
> > works:
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > >
> > > The Git tag is nifi-1.11.4-RC1
> > > The Git commit ID is 4d940bb151eb8d250b0319318b96d23c4a9819ae
> > >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=4d940bb151eb8d250b0319318b96d23c4a9819ae
> > >
> > > Checksums of nifi-1.11.4-source-release.zip:
> > > SHA256:
> a67ecb34f32cc1f070ebb006b6f05456a2ac663b12f708eadac67754194a6c63
> > > SHA512:
> > >
> >
> 2e04235c4d49a76319af7756289ce11554a412bf5f7dcb6dc3915fc931df9f067142820c297e83bc36cb1079fb8384794ef457a20dd00568761eed6621701953
> > >
> > > 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
> > >
> > > 45 issues were closed/resolved for this release:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12347022
> > >
> > > Release note highlights can be found here:
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.4
> > >
> > > 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.11.4
> > > [ ] +0 no opinion
> > > [ ] -1 Do not release this package because...
> >
> >
>

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

[Tony Kurc]

+1 (binding)

successfully went through the helper guide on mxlinux 18, did not discover
any issues with the signature, hashes, or build.

On Wed, Jan 22, 2020 at 8:48 AM Aldrin Piri  wrote:

> +1, binding
>
> comments:
> signature - good
> hashes - good
> L - good
> built and tested some simple flows in conjunction with registry on macos,
> debian
>
> thanks for organizing, Joe!
>
>
> On Wed, Jan 22, 2020 at 8:02 AM Mike Thomsen 
> wrote:
>
> > +1 binding. Ran a flow with a custom processor and verified the fix for
> > NIFI-7044.
> >
> > On Wed, Jan 22, 2020 at 3:15 AM 高橋喜秋  wrote:
> >
> > > +1 (non-binding)
> > >
> > > - [x] Non-RPM (usual) build with Java 8.
> > > - [x] Deploy on 3 node secured cluster in CentOS 7.7.0 and run on Java
> 8.
> > > - [x] Non-RPM (usual) build with Java 11.
> > > - [x] Deploy on 1 node non secured cluster in CentOS 7.7.0 and run on
> > Java
> > > 11.
> > >
> > > Thanks for working for the release!
> > >
> > > On 2020/01/19 20:21:02, Joe Witt  wrote:
> > > > Hello,
> > > >
> > > > I am pleased to be calling this vote for the source release of Apache
> > > NiFi
> > > > nifi-1.11.0.
> > > >
> > > > The source zip, including signatures, digests, etc. can be found at:
> > > >
> https://repository.apache.org/content/repositories/orgapachenifi-1155
> > > >
> > > > The source being voted upon and the convenience binaries can be found
> > at:
> > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.0/
> > > >
> > > > A helpful reminder on how the release candidate verification process
> > > works:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate
> > > >
> > > > The Git tag is nifi-1.11.0-RC3
> > > > The Git commit ID is 633408bce7ad34dad727ed9c4edfd36a224f3f12
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=633408bce7ad34dad727ed9c4edfd36a224f3f12
> > > >
> > > > Checksums of nifi-1.11.0-source-release.zip:
> > > > SHA256:
> > 0e2d77265fc7cedfbdb9588df1dd7f456fd18b6288d65eb5e21befe23af7c567
> > > > SHA512:
> > > >
> > >
> >
> 4880fa3482b3e8d8eed439848fe0a6596826d7ad46425a91b0dd4a4bcd178259327380b24045b7991dbdf8449abdfdda145786b6863eb603f6cef3b9e0ae8ec1
> > > >
> > > > 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
> > > >
> > > > 129 issues were closed/resolved for this release:
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346451
> > > >
> > > > Release note highlights can be found here:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.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.11.0
> > > > [ ] +0 no opinion
> > > > [ ] -1 Do not release this package because...
> > > >
> > >
> >
>

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.7.0 (RC1)

[Tony Kurc]

Looks like I missed the vote by a smidge, but I did work through the helper
guide on mxlinux 18 with no issues. So, I'll cast a post-vote +1!

On Sat, Jan 11, 2020 at 12:33 PM Arpad Boda  wrote:

> Apache NiFi Community,
>
> I am pleased to announce that the 0.7.0 release of Apache NiFi MiNiFi
> C++ passes with
> 5 +1 (binding) votes
> 2 +1 (non-binding) votes
> 0 0 votes
> 0 -1 votes
>
> Thanks to all who helped make this release possible.
>
> Here is the PMC vote thread:
>
> http://apache-nifi.1125220.n5.nabble.com/VOTE-Release-Apache-NiFi-MiNiFi-C-0-7-0-RC1-td29724.html
>
> On Sat, Jan 11, 2020 at 6:30 PM Arpad Boda  wrote:
>
> > +1 - verified build, checksums and execution on Debian.
> >
> > Thanks all for the documentation improvements, will adjust helper and
> > readme accordingly!
> >
> > On Sat, Jan 11, 2020 at 3:57 AM Andy LoPresto 
> > wrote:
> >
> >> +1 (binding)
> >>
> >> I encountered a number of obstacles during this validation, some of
> which
> >> are definitely because I haven’t worked on the C++ effort (or even built
> >> it) in at least 6 months. These are not complaints, just wrinkles I
> >> captured so we can improve this process for next time. Noted here for
> >> posterity:
> >>
> >> * The SHA-512 digest I calculated locally matched the email, but the
> >> .sha512 files are not published in the hosted server for any artifacts.
> >> * The GPG verification command in the helper email should include -v to
> >> show the underlying digest algorithm used
> >> * The wget commands have newlines inserted, which means they cannot be
> >> copied/pasted into the terminal without manual modification
> >> * The README section on bootstrapping helped immensely, but is not
> >> perfectly aligned with the current process
> >> * The wording of “disable tests…..disabled” is unclear (in this case it
> >> means that the tests will be run)
> >> * The bootstrap instructions are missing the directive to change into
> the
> >> build/ directory before running make (directory in example prompt is
> wrong)
> >> * The bootstrap instructions are missing the directive to untar the
> >> binary artifact and change into that directory before running
> >> ./bin/minifi.sh start
> >> * A sample flow (config.yml) with a GenerateFlowFile and LogAtttribute
> >> flow would be helpful to allow people to verify the successful install
> of
> >> MiNiFi without going through the full flow design in NiFi, export
> template,
> >> convert template process
> >>
> >> All in all, a lot of great work done on this release. Thanks Arpad.
> >>
> >>
> >> Andy LoPresto
> >> alopre...@apache.org
> >> alopresto.apa...@gmail.com
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> > On Jan 10, 2020, at 12:55 PM, Matt Gilman 
> >> wrote:
> >> >
> >> > +1 (binding)
> >> >
> >> > Ran through release helper. Verified signature, checksums, build,
> tests,
> >> > etc. Looks good.
> >> >
> >> > Thanks for RMing Arpad!
> >> >
> >> > On Fri, Jan 10, 2020 at 3:39 PM Kevin Doran 
> >> wrote:
> >> >
> >> >> +1 (binding)
> >> >>
> >> >> Ran through the steps in the release helper guide. Noticed a few
> >> >> release helper instructions that can be improved for next time (no
> >> >> mention of bootstrap.sh),
> >> >> but was able to figure it out by using the README file included in
> the
> >> >> source release.
> >> >>
> >> >> Hashes & sig all looked good. Was able to build, including the docker
> >> >> image. Tests
> >> >> all passed. Tested integration with a NiFi cluster with the 0.7.0
> >> >> minifi sending flow files over s2s and everything worked as expected.
> >> >>
> >> >> Overall, seems to be a very solid, polished release. Nice work all!
> >> >>
> >> >> On Fri, Jan 10, 2020 at 3:35 PM Joe Witt  wrote:
> >> >>>
> >> >>> +1 (binding)
> >> >>>
> >> >>> Comments
> >> >>> - Notice file copyright year needs to be 2020
> >> >>> - I did not enable python support but I get the minifi-python dir
> >> anyway
> >> >>> and log entry on startup such as
> >> >>>   Caught Exception ModuleNotFoundError: No module named 'google'
> >> >>>
> >> >>> Great progress with this release!  Nice work.  Building and running
> >> tests
> >> >>> was easier than I ever remember.
> >> >>>
> >> >>> Thanks
> >> >>>
> >> >>> On Fri, Jan 10, 2020 at 8:27 AM Dániel Bakai <
> bakaid.apa...@gmail.com
> >> >
> >> >>> wrote:
> >> >>>
> >>  +1, non-binding
> >> 
> >>  Verifications performed:
> >> 
> >>  SHA256 checksums downloaded: OK
> >>  SHA512 checksum of nifi-minifi-cpp-0.7.0-source.tar.gz sent in
> mail:
> >> OK
> >>  GPG signatures downloaded: OK
> >>  Git tag in email matches sources in
> >> >> nifi-minifi-cpp-0.7.0-source.tar.gz: OK
> >> 
> >>  bootstrap.sh with default options && make && make package && sudo
> >> make
> >> >> test
> >>  ARGS="-j4 --output-on-failure" && run package with a
> GenerateFlowFile
> >> >> ->
> >>  LogAttribute flow:
> >>  macOS 10.14.6: TailFileTests 

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

[Tony Kurc]

+1 (binding)

verified signature and checksums. built without issue on my ubuntu rig.

On Fri, Nov 1, 2019 at 8:00 PM Koji Kawamura  wrote:

> +1 (biding)
>
> Ran through the release helper guid. Built successfully and ran
> example flows worked as expected.
>
> Note for others using old macOS.
> I encountered test failure due to incompatibility between old macOS
> Sierra (10.12.6) and RocksDB 6.2.2 as follows. Recent macOS should be
> fine.
> https://github.com/facebook/rocksdb/issues/4862
>
> [ERROR] Tests run: 10, Failures: 0, Errors: 9, Skipped: 0, Time
> elapsed: 0.167 s <<< FAILURE! - in
> org.apache.nifi.rocksdb.TestRocksDBMetronome
> [ERROR] testColumnFamilies(org.apache.nifi.rocksdb.TestRocksDBMetronome)
>  Time elapsed: 0.08 s  <<< ERROR!
> java.lang.UnsatisfiedLinkError:
>
> /private/var/folders/wd/mgqn9pqx07x43hqcg9s4t0fhgn/T/librocksdbjni6955104638219729855.jnilib:
>
> dlopen(/private/var/folders/wd/mgqn9pqx07x43hqcg9s4t0fhgn/T/librocksdbjni6955104638219729855.jnilib,
> 1): Symbol not found: __ZdlPvSt11align_val_t
>   Referenced from:
>
> /private/var/folders/wd/mgqn9pqx07x43hqcg9s4t0fhgn/T/librocksdbjni6955104638219729855.jnilib
>   Expected in: /usr/lib/libc++.1.dylib
> in
> /private/var/folders/wd/mgqn9pqx07x43hqcg9s4t0fhgn/T/librocksdbjni6955104638219729855.jnilib
> at
> org.apache.nifi.rocksdb.TestRocksDBMetronome.testColumnFamilies(TestRocksDBMetronome.java:163)
>
> Thanks Joe for RMing!
>
> Koji
>
> On Sat, Nov 2, 2019 at 5:26 AM Kevin Doran  wrote:
> >
> > +1 (binding)
> >
> > Ran through the release helper steps, ran the resulting assembly,
> > secured it, and tested integration with secure registry. All working
> > well.
> >
> > Nice work all! Thanks Joe for RM'ing!
> >
> > On Fri, Nov 1, 2019 at 1:11 PM Andrew Lim 
> wrote:
> > >
> > > +1 (non-binding)
> > >
> > > -Ran full clean install on OS X (10.14.2)
> > > -Tested secure NiFi with secure NiFi Registry
> > > -Ran basic flows successfully
> > > -Tested parameters/parameter contexts functionality and policies
> > > -Reviewed core UI and documentation fixes/updates
> > >
> > > Drew
> > >
> > > > On Oct 29, 2019, at 1:32 PM, 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=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: [ANNOUNCE] New Apache NiFi Committer Dániel Bakai

[Tony Kurc]

Congratulations Dániel!

On Fri, Oct 25, 2019, 8:21 PM Otto Fowler  wrote:

> std::cout << “Congratulations” << std::endl;
>
>
>
>
> On October 25, 2019 at 12:38:20, Aldrin Piri (ald...@apache.org) wrote:
>
> Apache NiFi community,
>
> On behalf of the Apache NiFI PMC, I am very pleased to announce that Dániel
> has accepted the PMC's invitation to become a committer on the Apache NiFi
> project. We greatly appreciate all of Dániel's hard work and generous
> contributions to the project. We look forward to continued involvement
> in the project.
>
> Dániel has provided numerous contributions to the MiNiFi C++ codebase,
> discovering and providing fixes for bugs, new functionality, and improving
> build processes. Dániel is also a staple in review processes and
> approaches each interaction with great communication and professionalism.
>
> Welcome and congratulations!
> AP
>

Re: Re: [Discuss] Data prioritization - A proposed solution

[Tony Kurc]

On FBP purity - even absent this implementation, there are "global"
resources being contended over (disk, network, threads). Absent infinite
capacity in all those things, I don't think a pure implementation is
possible. In my opinion, what is being discussed is the best way of coping
with one aspect of resource contention while compromising as little as
possible.

Tony

On Fri, Oct 18, 2019 at 3:29 PM Joe Witt  wrote:

> I should clarify a bitIt is a perfectly fine thing to have an
> alternative queue implementation which will have awareness that other high
> priority data exists elsewhere and thus will intentionally respond as if
> data is not available on a given queue so that other queues with higher
> priority data will be serviced first.  This will be helpful for ensuring
> highest priority data gets worked first.
>
> My concerns relating to FBP purity as Andy brought up are important
> considerations but they would not necessarily block the inclusion of such
> an implementation.  We need to see it and talk through it for its own sake
> - not FBPs.
>
> At this stage I think you see there are plenty of folks interested in what
> this could mean.  It is clearly touching on something that could benefit
> from new ideas/improvement.  Hopefully you choose to make a PR/JIRA for it
> as that is probably the next best step.
>
>
>
> On Fri, Oct 18, 2019 at 1:59 PM Joe Witt  wrote:
>
> > ...I was of course thinking the same thing about the fact this really
> does
> > violate the point of the flow based programming construct.  But I only
> > think it is the implementation that violates this.  Not the idea.  The
> idea
> > is that some portions of the flow should have higher priority than others
> > for execution/queuing.  It is the implementation which does this by
> > coupling logic of how a queue behaves with the fact that higher priority
> > data lives elsewhere and it then artificially says 'no work right now go
> do
> > something more important'.  If we stay focused on the spirit of the idea
> I
> > think there is something really interesting here that is
> > additive/beneficial to the FBP constructs.
> >
> > I am slightly emboldened here in that having spoken with J Paul Morrison
> > about NiFi and FBP he felt like we had done some things which were
> > additive/beneficial to FBP and felt we were more like Classical FBP than
> > many other things even though we've not implemented named ports for
> > components (yet).
> >
> > That said, I do also feel like the real core need Jon's idea addresses is
> > possibly better served by it being easier to deploy resource constrained
> > NiFi Clusters or having things like stateless-nifi as an executor.
> >
> > In any event - this is a good discussion area and I'm looking forward to
> > seeing how this evolves.
> >
> >
> >
> > On Fri, Oct 18, 2019 at 1:50 PM Andy LoPresto 
> > wrote:
> >
> >> This is an interesting idea to solve an admitted problem, but I wonder
> >> how it comports with the core tenets of Flow Based Programming on which
> >> NiFi is modeled. This seems to introduce globally-coupled dependencies
> >> between all queues in a flow, where another solution (flow segment-based
> >> resource allocation) might solve this problem without requiring
> per-queue
> >> contention on every cycle. I think with the stateless NiFi work there
> has
> >> been some discussion around being able to control the resource
> allocation
> >> for a flow segment. Sam Hjemfelt, any thoughts here?
> >>
> >>
> >> Andy LoPresto
> >> alopre...@apache.org
> >> alopresto.apa...@gmail.com
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> > On Oct 17, 2019, at 8:54 AM, Kessler, Jon 
> >> wrote:
> >> >
> >> > Joe, hopefully I addressed all of your questions:
> >> >
> >> > Your interpretation of the scheduling aspect is correct. These queues
> >> will pretend to be empty a certain % of the time if higher priority data
> >> recently moved elsewhere. That % is configurable on a per rule basis
> which
> >> allows the operator to determine how much to stagger the data associated
> >> with each rule. That % is also how the rules are ranked in terms of
> order
> >> of priority. The higher the %, the more often a rule will make use of
> its
> >> threads so the higher its priority is considered to be.
> >> >
> >> > Administration: You are correct that the ruleset is provided at the
> >> flow controller level but will be leveraged by all connections
> regardless
> >> of whether or not they use the BucketPrioritizer (more details on this
> >> below). This overall solution only works if all FlowFileQueues are of
> this
> >> new implementation which is why I tied it to nifi.properties settings.
> >> >
> >> > The sorting function here takes place on insertion into any connection
> >> on which a BucketPrioritizer is set. Once a FlowFile has been sorted
> into a
> >> bucket we maintain that state so that each time it moves into a new
> >> connection we already know 

[ANNOUNCE] New Apache NiFi Committer Rob Fellows

[Tony Kurc]

Apache NiFi community,
On behalf of the Apache NiFI PMC, I am very pleased to announce that Rob
has accepted the PMC's invitation to become a committer on the Apache NiFi
project. We greatly appreciate all of Rob's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

What stood out with Rob are his regular code contributions and reviews on
many parts of the project to include NiFi, NiFi FDS, and NiFi Registry
since early this year. Additionally, he's been doing the
not-always-glamorous work of helping verify releases, which was a huge
assist in getting NiFi 1.9.1, NiFi Registry 0.4.0 and 0.5.0, and NiFi FDS
0.2.0 out to the community.

Welcome and congratulations!
Tony

Re: [VOTE] Create NiFi Standard Libraries sub-project

[Tony Kurc]

+1 (binding)

On Wed, Sep 4, 2019 at 12:29 AM Aldrin Piri  wrote:

> +1, binding
>
> On Tue, Sep 3, 2019 at 19:46 Yolanda Davis 
> wrote:
>
> > +1 Create NiFi Standard Libraries (binding)
> >
> > On Tue, Sep 3, 2019 at 7:03 PM Koji Kawamura 
> > wrote:
> >
> > > +1 Create NiFi Standard Libraries (binding)
> > >
> > > On Wed, Sep 4, 2019 at 7:25 AM Mike Thomsen 
> > > wrote:
> > > >
> > > > +1 binding
> > > >
> > > > On Tue, Sep 3, 2019 at 5:33 PM Andy LoPresto 
> > > wrote:
> > > >
> > > > > +1, create NiFi Standard Libraries (binding)
> > > > >
> > > > > Andy LoPresto
> > > > > alopre...@apache.org
> > > > > alopresto.apa...@gmail.com
> > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > > >
> > > > > > On Sep 3, 2019, at 2:16 PM, Bryan Bende 
> wrote:
> > > > > >
> > > > > > All,
> > > > > >
> > > > > > In a previous thread there was a plan discussed to restructure
> some
> > > of
> > > > > > the repositories in order to address several different issues,
> such
> > > as
> > > > > > build time, reusability of code, and eventually separating how
> the
> > > > > > framework and extensions are released [1][2].
> > > > > >
> > > > > > The overall plan requires many steps to get there, so I'd like to
> > > > > > propose starting with a small actionable step - the creation of a
> > new
> > > > > > sub-project called NiFi Standard Libraries (formerly referred to
> as
> > > > > > nifi-commons).
> > > > > >
> > > > > > Project Name: Apache NiFi Standard Libraries
> > > > > > Git Repository: nifi-standard-libraries
> > > > > > JIRA: NIFILIBS
> > > > > >
> > > > > > Description:
> > > > > >
> > > > > > A collection of standard implementations used across the NiFi
> > > ecosystem.
> > > > > >
> > > > > > Candidate Libraries:
> > > > > >
> > > > > > In general, each library may consist of multiple Maven modules,
> and
> > > > > > should be independent from the rest of the ecosystem, and from
> > other
> > > > > > libraries within NiFi Standard Libraries.
> > > > > >
> > > > > > In addition, each library may make it's own decision about
> whether
> > it
> > > > > > is considered a public facing extension point/API, or an internal
> > > > > > library that may be changed at any time. This should be
> documented
> > in
> > > > > > a README at the root of each library, such as
> > > > > > nifi-standard-libraries/nifi-xyz/README.
> > > > > >
> > > > > > An initial library that has been discussed was referred to as
> > > > > > 'nifi-security' and would centralize much of the security related
> > > code
> > > > > > shared by NiFi and NiFi Registry, such as shared security APIs,
> and
> > > > > > implementations for various providers, such as LDAP/Kerberos/etc.
> > > > > >
> > > > > > A second candidate library would be an optimistic-locking library
> > > > > > based on NiFi's revision concept. Currently this has been created
> > > > > > inside nifi-registry for now [3], but could be moved as soon as
> > > > > > nifi-standard-libraries exists.
> > > > > >
> > > > > > (This list does not have to be final in order to decide if we are
> > > > > > creating NiFi Standard Libraries or not)
> > > > > >
> > > > > > Integration & Usage:
> > > > > >
> > > > > > Once NiFi Standard Libraries is created, the community can start
> > > > > > creating and/or moving code there and perform releases as
> > necessary.
> > > A
> > > > > > release will consist of the standard Apache source release, plus
> > > > > > artifacts released to Maven central. The community can then
> decide
> > > > > > when it is appropriate to integrate these released libraries into
> > one
> > > > > > of our downstream projects.
> > > > > >
> > > > > > For example, if we create a nifi-security library in
> > > > > > nifi-standard-libraries, we can release that whenever we decide,
> > but
> > > > > > we may not integrate it into NiFi or NiFi Registry until it makes
> > > > > > sense for a given release of those projects.
> > > > > >
> > > > > > This vote will be open for 48 hours, please vote:
> > > > > >
> > > > > > [ ] +1 Create NiFi Standard Libraries
> > > > > > [ ] +0 no opinion
> > > > > > [ ] -1 Do not create NiFi Standard Libraries because...
> > > > > >
> > > > > > [1]
> > > > >
> > >
> >
> http://apache-nifi.1125220.n5.nabble.com/discuss-Splitting-NiFi-framework-and-extension-repos-and-releases-td27499.html
> > > > > > [2]
> > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFIREG/NiFi+Project+and+Repository+Restructuring
> > > > > > [3]
> > > > >
> > >
> >
> https://github.com/apache/nifi-registry/tree/master/nifi-registry-core/nifi-registry-revision
> > > > >
> > > > >
> > >
> >
> >
> > --
> > --
> > yolanda.m.da...@gmail.com
> > @YolandaMDavis
> >
>

Re: [ANNOUNCE] New Apache NiFi PMC member Peter Wicks

[Tony Kurc]

Congratulations Peter!!

On Thu, May 30, 2019 at 11:21 AM Aldrin Piri  wrote:

> NiFi Community,
>
> On behalf of the Apache NiFi PMC, I am pleased to announce that Peter Wicks
> has accepted the PMC's invitation to join the Apache NiFi PMC.
>
> Peter's contributions have been plentiful in code, community, reviews and
> discussion after becoming a committer in November 2017.  His impact across
> NiFi has lead to improvements surrounding Kerberos, GetFile, ListFile,
> Clustering, Node Offload, Recordset Writers, HDFS, and Database related
> processors among others.
>
> Thank you for all your contributions and welcome to the PMC, Peter!
>
> --aldrin
>

Re: [VOTE] Release Apache NiFi 1.9.1 (rc1)

[Tony Kurc]

+1 (binding)

went through helper with clean mvn repo, everything checks out and built
beautifully

On Thu, Mar 14, 2019 at 9:27 PM Koji Kawamura 
wrote:

> +1 binding
>
> Went through release helper guide.
> Thanks Joe for managing this release!
>
> On Fri, Mar 15, 2019 at 9:34 AM Aldrin Piri  wrote:
> >
> > +1, binding
> >
> > comments:
> > hashes and signature looked good
> > build, tests, and contrib check good on Ubuntu and MacOS
> >
> >
> > On Thu, Mar 14, 2019 at 6:58 PM James Wing  wrote:
> >
> > > +1 (binding) - Ran through the release helper, checked the signatures,
> > > license/readme, and ran the full build.  Ran a simple test flow.
> > >
> > > Thanks, Joe, for putting this release together!
> > >
> > > On Tue, Mar 12, 2019 at 10:49 PM Joe Witt  wrote:
> > >
> > > > Hello,
> > > >
> > > > I am pleased to be calling this vote for the source release of Apache
> > > NiFi
> > > > 1.9.1.
> > > >
> > > > The source zip, including signatures, digests, etc. can be found at:
> > > >
> https://repository.apache.org/content/repositories/orgapachenifi-1138
> > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.9.1-rc1/
> > > >
> > > > The Git tag is nifi-1.9.1-RC1
> > > > The Git commit ID is a5cedc4ad39b17bee97303b63b620f9ac3dddc79
> > > >
> > > >
> > >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=a5cedc4ad39b17bee97303b63b620f9ac3dddc79
> > > >
> > > > Checksums of nifi-1.9.1-source-release.zip:
> > > > SHA256:
> 7099abb33e26445788630b69f38b8788117cdd787b7001752b4893d8b6c16f38
> > > > SHA512:
> > > >
> > > >
> > >
> 678c2ee32f7db8c73393178f329c574315b1b892084b822f9b7a6dc5bc159d5e7e1169812d9676a72f738d03fd2f4366f2b67ddee152b56c8a77751fd5cbb218
> > > >
> > > > 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
> > > >
> > > > 19 issues were closed/resolved for this release:
> > > >
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12345163
> > > >
> > > > Release note highlights can be found here:
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.9.1
> > > >
> > > > 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.9.1
> > > > [ ] +0 no opinion
> > > > [ ] -1 Do not release this package because...
> > > >
> > >
>

Re: [VOTE] Release Apache NiFi 1.9.0 (rc2)

[Tony Kurc]

+1 (binding)

- Went through helper on ubuntu 16.04 (x86) without issue
- ran through some very simple flows


On Tue, Feb 19, 2019 at 5:07 PM Andrew Lim 
wrote:

> +1 (non-binding)
>
> -Ran full clean install on OS X (10.14.2)
> -Ran a flow moving data from MySQL into Kudu (QueryDatabaseTable & updated
> PutKudu processor)
> -Reviewed documentation additions/updates
>
> Drew
>
> > On Feb 16, 2019, at 10:50 PM, Joe Witt  wrote:
> >
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> NiFi
> > nifi-1.9.0.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1136
> >
> > The Git tag is nifi-1.9.0-RC2
> > The Git commit ID is 45bb53d2aafd6ec5cb6bb794b3f7f8fc8300a04b
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=45bb53d2aafd6ec5cb6bb794b3f7f8fc8300a04b
> >
> > Checksums of nifi-1.9.0-source-release.zip:
> > SHA256: f8d2987a98903f0c00c50677f3a6ad361e417c6021f5179280cbe9ca838695da
> > SHA512:
> >
> 2e77c420f932514417693584b4708a534df398e344dac7c1471f55cc382b7493d73b10ebc0d9e58562eb989c1f0b72980d6d18a2555883267f0bc08f092f30fe
> >
> > 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
> >
> > 160 issues were closed/resolved for this release:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12344357
> >
> > Release note highlights can be found here:
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.9.0
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.9.0-rc2/
> >
> > 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.9.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
>
>

[ANNOUNCE] New Apache NiFi Committer Ed Berezitsky

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Ed has
accepted the PMC's invitation to become a committer on the Apache NiFi
project. We greatly appreciate all of Ed's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

Ed has been contributing code to the project through most of 2018, in areas
such as HBase, HDFS, and fixing some long standing bugs. Also, many of you
have had the pleasure of interacting with him on the dev and users mailing
lists, epitomizing The Apache Way.

Welcome and congratulations!

Tony

[ANNOUNCE] New Apache NiFi Committer Nathan Gough

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Nathan
has accepted the PMC's invitation to become a committer on the Apache NiFi
project. We greatly appreciate all of Nathan's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

What stood out for the PMC was Nathan's long history of code contribution
especially in the area of security, and his always helpful conduct on the
mailing lists, the jiras, reviews, and releases. Thanks Nathan!

Welcome and congratulations!

- Tony

Re: [DISCUSS] Early, voluntary relocation to GitBox

[Tony Kurc]

+1, sounds like a great idea

On Sat, Dec 8, 2018 at 7:44 AM Mike Thomsen  wrote:

> +1
>
> On Fri, Dec 7, 2018 at 9:08 PM Sivaprasanna 
> wrote:
>
> > +1 (non-binding)
> >
> > I’m in. Thanks for doing it, Aldrin.
> >
> >
> > On Sat, 8 Dec 2018 at 7:32 AM, James Wing  wrote:
> >
> > > +1, thanks for volunteering.
> > >
> > > > On Dec 7, 2018, at 13:39, Kevin Doran 
> wrote:
> > > >
> > > > +1
> > > >
> > > > On 12/7/18, 15:17, "Andy LoPresto"  wrote:
> > > >
> > > >+1.
> > > >
> > > >Andy LoPresto
> > > >alopre...@apache.org
> > > >alopresto.apa...@gmail.com
> > > >PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
> EF69
> > > >
> > > >> On Dec 7, 2018, at 11:11 AM, Aldrin Piri 
> > wrote:
> > > >>
> > > >> Hey folks,
> > > >>
> > > >> Daniel Gruno sent an email to the dev list about the deprecation of
> > our
> > > >> git-wip repositories [1] (these are the canonical repos that
> > committers
> > > >> push changes to and are currently mirrored to GitHub) and
> > transitioning
> > > to
> > > >> GitBox [2].
> > > >>
> > > >> As highlighted in that email, this will not be an optional change,
> > only
> > > in
> > > >> when and how it happens.  There was a previous discussion over this
> > > topic
> > > >> [3] where it was generally well received but I think some of the
> > > logistics
> > > >> were never mapped out and thus the actual request to do so was never
> > > >> executed.
> > > >>
> > > >> I am proposing we volunteer for the early relocation.  The process
> > > looks to
> > > >> be fairly straightforward and should ultimately only result in
> > requiring
> > > >> our contributors to add/replace their original git-wip based
> remotes.
> > > >>
> > > >> If folks are in favor, I am happy to file the requisite INFRA ticket
> > and
> > > >> provide the associated communication/docs to the community to make
> > this
> > > >> happen.  Again, this is only about making the choice to perform this
> > > >> migration now, in a coordinated manner, in lieu of the mass
> migration
> > > that
> > > >> would happen later.
> > > >>
> > > >> From a project management standpoint, I think it is a nice bit of
> > > >> functionality that lets us better curate our open PRs and, given my
> > > prior
> > > >> interest in the subject, would like to see it happen.
> > > >>
> > > >> --aldrin
> > > >>
> > > >> [1]
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/8247bb17671d6131b1d7a646b4c018b21aac390c4f627d8fb1f421b2@%3Cdev.nifi.apache.org%3E
> > > >> [2] https://gitbox.apache.org/
> > > >> [3]
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/de5e103994f356b1b8a572410938eef44af8cb352210e35305c04bc9@%3Cdev.nifi.apache.org%3E
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache NiFi 1.8.0 (RC3)

[Tony Kurc]

+1 (binding)

ran through helper. ran some fairly simple tests.

On Thu, Oct 25, 2018 at 3:16 PM Kevin Doran  wrote:

> +1 (binding)
>
> Ran through the steps in the helper guide.
> Ran a test by Running NiFi, connecting with registry, and
> versioning/importing/running flows.
>
> Thanks for RM'ing this release, Jeff!
>
> Kevin
>
> On 10/25/18, 12:48, "Joe Witt"  wrote:
>
> +1 (binding)
>
> Did the usual checks.  Ran into NIFI-5745.  The new features such as
> load balancing will be hugely valuable.
>
> Great work by the whole community.  Thanks Jeff for the RM work!
>
> Joe
> On Thu, Oct 25, 2018 at 10:25 AM Laszlo Horvath
>  wrote:
> >
> > +0 (non-binding)
> >
> > I verified the followings:
> > - signature
> > - hashes
> > - successful build
> >
> > Regards,
> > Laszlo
> >
> >
> > On 25/10/2018, 12:54, "koter...@yahoo-corp.jp" <
> koter...@yahoo-corp.jp> wrote:
> >
> > +0 (non-binding)
> >
> > I have:
> >  - verified hashes
> >  - confirmed a build
> >  - started a secure cluster
> >  - tested some simple dataflows
> >
> > However, on a secure cluster "with wildcard certs", I have found
> a bug in load-balancing. I just made a JIRA ticket and a PR for that.
> > https://issues.apache.org/jira/browse/NIFI-5752
> >
> >
> > Kotaro Terada
> >
> >
> >
> > 
> > 差出人: Jeff 
> > 送信日時: 2018年10月23日 14:56
> > 宛先: NiFi Dev List
> > 件名: [VOTE] Release Apache NiFi 1.8.0 (RC3)
> >
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of
> Apache NiFi
> > nifi-1.8.0.
> >
> > The source zip, including signatures, digests, etc. can be found
> at:
> >
> https://repository.apache.org/content/repositories/orgapachenifi-1135
> >
> > The Git tag is nifi-1.8.0-RC3
> > The Git commit ID is 98aabf2c50f857efc72fd6f2bfdd9965b97fa195
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=98aabf2c50f857efc72fd6f2bfdd9965b97fa195
> >
> > Checksums of nifi-1.8.0-source-release.zip:
> > SHA256:
> 6ec21c36ebb232f344493a4aeb5086eed0c462c576e11a79abed8149bc8b65c3
> > SHA512:
> >
>  
> 846aecd4eb497a3b7dee7d1911b02453b8162b6c87e39f3df837744a478212e2e3e3615921079d29c2804671f26ecd05b04ce46a4bb69e8911fc185e27be9c24
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/jstorck.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 209 issues were closed/resolved for this release:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12343482
> >
> > Release note highlights can be found here:
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.8.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.8.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> >
>
>

Re: [CANCEL] [VOTE] Release Apache NiFi 1.8.0

[Tony Kurc]

While likely not an issue with the release - I have a fresh install of
Ubuntu 18.04 I was verifying on and hit a heisenbug condition. TestPutUDP
was failing in weird fashion because as best as I can tell the default send
buffer size in the operating system was smaller than the default send
buffer of the processor, and somehow this caused the java (openjdk 1.8)
process to die on occasion, but every attempt I made to instrument has
failed. I bump up the operating system send buffer to 1M and do a build, no
problems. But the default (212992) bombs out about 75% of the time on my
box when doing a full build. Pretty sure it won't hit most, and it doesn't
make complete sense to me that the condition would manifest in such a way,
I just wanted to put it out here in case others have the same issue.

On Fri, Oct 19, 2018 at 6:34 PM Jeff  wrote:

> Given the issue with the SSLContextService, I'm canceling the vote.
>
> I will create RC2 tomorrow, with a 96-hour voting window since it's the
> weekend.
>
> On Fri, Oct 19, 2018 at 4:35 PM Nathan Gough  wrote:
>
> > -1 (revote)
> >
> > On further testing I have found that the SSLContextService does not work
> > as expected due to this ticket
> > https://jira.apache.org/jira/browse/NIFI-4558 and the related PR. This
> > makes it difficult or impossible to use the SSLContextService as I
> believe
> > the customValidate() method takes in user input and not the default
> > settings. I would say this is a blocker for nifi-1.8.0-RC1. I have
> > submitted a PR to revert this change:
> > https://github.com/apache/nifi/pull/3097.
> >
> > My apologies,
> > Nathan
> >
> > On 10/19/18, 3:29 PM, "Andrew Lim"  wrote:
> >
> > +1 (non-binding)
> >
> > -Ran full clean install on OS X (10.11.6)
> > -Tested secure cluster; used UI to: disconnect/connect nodes; offload
> > nodes; load balance connections
> > -Reviewed documentation
> >
> > Drew
> >
> > > On Oct 17, 2018, at 11:59 PM, Jeff  wrote:
> > >
> > > Hello,
> > >
> > > I am pleased to be calling this vote for the source release of
> > Apache NiFi
> > > nifi-1.8.0.
> > >
> > > The source zip, including signatures, digests, etc. can be found
> at:
> > >
> > https://repository.apache.org/content/repositories/orgapachenifi-1133
> > >
> > > The Git tag is nifi-1.8.0-RC1
> > > The Git commit ID is 9b02d58626ca874ed2ed3e0bbe530512cfa0dbf8
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=9b02d58626ca874ed2ed3e0bbe530512cfa0dbf8
> > >
> > > Checksums of nifi-1.8.0-source-release.zip:
> > > SHA256:
> > 3ec90a7f153e507d7bba2400d6dafac02641d6f7afc7a954fed959191073ce21
> > > SHA512:
> > >
> >
> 8b9d944da1833bfb645f502107cab98a555e3b2a7602c5ff438407272c86defdeebe18625c5ad9dfb3f344397314569e97220a35f2438182a79a700caa90721e
> > >
> > > Release artifacts are signed with the following key:
> > > https://people.apache.org/keys/committer/jstorck.asc
> > >
> > > KEYS file available here:
> > > https://dist.apache.org/repos/dist/release/nifi/KEYS
> > >
> > > 204 issues were closed/resolved for this release:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12343482
> > >
> > > Release note highlights can be found here:
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.8.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.8.0
> > > [ ] +0 no opinion
> > > [ ] -1 Do not release this package because...
> >
> >
> >
> >
> >
>

[ANNOUNCE] New NiFi PMC member Jeremy Dyer

[Tony Kurc]

All,

On behalf of the Apache NiFi PMC, I am pleased to announce that Jeremy Dyer
has accepted the PMC's invitation to join the Apache NiFi PMC.

Jeremy has been a long-time contributor to the project - across many
different parts of the project to include NiFi and and MiNiFi, contributing
code, reviews, release verification, and help on the mailing lists. He's
performed the challenging, detail oriented work of acting as a release
manager for both the Java and C++ versions of MiNiFi (0.5.0 of each).

Congratulations Jeremy and well deserved!

Tony

[ANNOUNCE] New NiFi PMC member Kevin Doran

[Tony Kurc]

NiFi Community,

On behalf of the Apache NiFi PMC, I am pleased to announce that Kevin Doran
has accepted the PMC's invitation to join the Apache NiFi PMC.

In addition to being a regular code contributor to the project for quite
some time, Kevin has been hard to miss on the mailing lists, especially on
NiFi Registry threads. We all appreciate his hard work getting releases
"out the door", helping verify releases and recently doing release manager
duty for the NiFi Registry 0.2.0.

Please join us in congratulating and welcoming Kevin to the Apache NiFi PMC.

Tony

Re: Apache NiFi contributor access

[Tony Kurc]

I'll take care of that.

On Sun, Jul 29, 2018 at 4:32 AM, Kumara M S, Hemantha (Nokia -
IN/Bangalore)  wrote:

> Hi,
>
> I would like to get contributor access to Apache Nifi on JIRA. Can you
> please add me to contributor list? My username is 'hemantha.kumara' .
>
> Thanks,
> Hemantha
>
>

Re: [VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Tony Kurc]

+1 (binding)

License + notice look good
built without issue
hashes and signature look good
Tested using a really simple flow

On Sun, Jul 1, 2018 at 1:42 PM, Jeff  wrote:

> +1, binding
>
> Ran through the release helper guide
> Created a simple flow for MiNiFi in NiFi, used the transform of the MiNiFi
> toolkit to create a config.yml
> Started MiNiFi with the config.yml created by the MiNiFi toolkit
> Observed the results in NiFi, working as expected.
>
> On Fri, Jun 29, 2018 at 6:59 PM Andy LoPresto 
> wrote:
>
> > +1, binding
> >
> > Verified all keys and checksums, ran through all the builds, verified
> > tests and contrib-check, and the existence of LICENSE/NOTICE/README at
> > appropriate locations. A couple minor points on the release process below
> > (and some other non-blocking issues that I will open as Jiras).
> >
> > * Now that MD5 is deprecated, I believe we agreed to provide a SHA-512
> > signature as well. The release guide should be updated to include this
> for
> > next time.
> > * The release helper should specify that LICENSE, NOTICE, and README are
> > in minifi-assembly/target*/minifi-0.5.0-bin/minifi-0.5.0/*
> >
> > Andy LoPresto
> > alopre...@apache.org
> > *alopresto.apa...@gmail.com *
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Jun 29, 2018, at 8:29 AM, Aldrin Piri  wrote:
> >
> > Hi folks,
> >
> > I worked with Jeremy to resolve the discrepancy and we were able to get
> the
> > commits/tag in question from the Maven release plugin pushed to the repo.
> >
> > The minifi-0.5.0-RC2 tag is correct in pointing to the source of the...
> > source commit 58b8c598c0866c8f1200164ab14f3df0d632d522 which was
> initiated
> > from the last commit on master, 05f516d3da33a0547ccfad34241450
> 4cdacd4a68.
> >
> > Links for reference:
> > tag:
> > * https://github.com/apache/nifi-minifi/tree/minifi-0.5.0-RC2
> > *
> >
> > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=
> shortlog;h=refs/tags/minifi-0.5.0-RC2
> >
> > RC2 branch commit:
> > *
> >
> > https://github.com/apiri/nifi-minifi/commit/
> 58b8c598c0866c8f1200164ab14f3df0d632d522
> > *
> >
> > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> 58b8c598c0866c8f1200164ab14f3df0d632d522
> >
> > --aldrin
> >
> >
> > On Fri, Jun 29, 2018 at 7:59 AM Jeff Zemerick 
> > wrote:
> >
> > +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/
> >
> > <
> >
> > 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 

Re: [DISCUSS] Tar + Gzip vs. Zip

[Tony Kurc]

My preference is zip.

On Tue, Jun 26, 2018, 9:21 AM Josh Elser  wrote:

>
>
> On 6/25/18 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.
>
> I'm not aware of any ASF policy. I think it mostly stems from default
> convention you get out of the maven-assembly-plugin.
>
> > [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

[Tony Kurc]

+1

Verified hashes and signature.
Notice and license look good
Built okay on my Ubuntu 16.04 box. Had a few problems on my windows 10 box,
but believe them to be environment rather than a problem with the build
Ran a few test flows


On Fri, Jun 22, 2018, 3:48 PM Scott Aslan  wrote:

> +1 binding
>
> Went through the release helper guide
> Tested unsecured standalone NiFi + unsecured NiFi Registry (0.2.0)
>
> Thanks for RM'ing A-Lo!
>
> On Fri, Jun 22, 2018 at 2:17 PM Andrew Lim 
> wrote:
>
> > +1 (non-binding)
> >
> > -Ran full clean install on OS X (10.11.6)
> > -Tested integration with NiFi Registry (0.2.0)
> > -Reviewed resolved “Core UI” component Jiras and spot checked inclusion
> in
> > build
> > -Reviewed documentation.  Found one minor issue with an image in the User
> > Guide [1]
> >
> > Drew
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-5330
> >
> >
> > > On Jun 20, 2018, at 3:16 AM, Andy LoPresto 
> 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=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: Unable to install Apachi nifi on my unix box

[Tony Kurc]

Srinivasarao,
I think you attempted to attach an image with the error which did not make
it through to the email list.

Tony

On Tue, Jun 12, 2018 at 10:03 AM, Sivaprasanna 
wrote:

> What error do you get when you run it? Please share it over here. BTW,
> which version of Apache NiFi are you using?
>
> Thanks,
> Sivaprasanna
>
> On Tue, Jun 12, 2018 at 7:24 PM, Srinivasa Rao Potla <
> srinivasarao.po...@infosys.com> wrote:
>
> > Hi Team,
> >
> >
> >
> > I have unable to run the below step , I have downloaded the as per github
> > steps .
> >
> >
> >
> > But unable to start the below step to start the apache nifi
> >
> > ./bin/nifi.sh start
> >
> >
> >
> >
> >
> >
> >
> > Regards,
> >
> > Srinivasarao Potla
> >
> > +91 8886210
> >
> > www.infosys.com
> >
> >
> >
>

[ANNOUNCE] New NiFi PMC member Mike Thomsen

[Tony Kurc]

 NiFi community,
On behalf of the Apache NiFi PMC, I am pleased to announce that Mike
Thomsen has accepted the PMC's invitation to join the Apache NiFi PMC.  We
greatly appreciate all of Mike's hard work and generous contributions to
the project. We look forward to continued involvement in the project.

Mike was announced as a committer a few months ago, and in that time I'm
sure many have noticed Mike's increased involvement in the areas we look
for in PMC members - building the community by helping people with issues,
ensuring the project follows ASF best practices, participation in
discussions, and helping others contribute (in addition to contributing his
own code and documentation). He's been a great advocate of the project and
of the Apache Way.

Congratulations and welcome, Mike!

Tony

[ANNOUNCE] New Apache NiFi Committer Sivaprasanna Sethuraman

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that
Sivaprasanna has accepted the PMC's invitation to become a committer on the
Apache NiFi project. We greatly appreciate all of Sivaprasanna's hard work
and generous contributions to the project. We look forward to continued
 involvement in the project.

Sivaprasanna has been working with the community on the mailing lists, and
has a big mix of code and feature contributions to include features and
improvements to cloud service integrations like Azure, AWS, and Google
Cloud.

Welcome and congratulations!

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.5.0

[Tony Kurc]

+1 (binding)

-verified signature and hashes
-verified build on a slightly weird ubuntu 16.04 x86_64 (had a tough time
with dependencies, but that was likely my environment). Got about 25%
through a build on a clean Ubuntu MATE 16.04 on a raspberry pi 3, but that
was looking good.
-due to limited time, ran a couple very simple flows
-reviewed LICENSE and NOTICE, saw no issues

On Sun, Jun 3, 2018 at 6:24 PM, Jeremy Dyer  wrote:

> Tony - thanks for trying to verify the release! Always great to have
> people helping out. Your right we do have enough votes for a pass though
> but it's always great to have more feedback in case we missed something.
> Sorry about the equipment failures and let me know if there is anything I
> can o to help
>
> Thanks - Jeremy Dyer
> ____
> From: Tony Kurc 
> Sent: Sunday, June 3, 2018 6:02:28 PM
> To: dev@nifi.apache.org
> Subject: Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.5.0
>
> All, I haven't been able to verify this release due to some equipment
> failure.. it looks like there is enough votes to pass, but I'm going to
> keep trying.
>
> On Sun, Jun 3, 2018, 5:58 PM Joe Witt  wrote:
>
> > +1 (binding)
> >
> > Confirmed sigs, hashes, commit.
> > Built on Fedora 28
> > Checked L  Wow that thing is serious!  Nicely done.
> >
> > Ran flow example flow on fedora 28 build against latest nifi using
> > example minificpp flow
> > Ran flow example on osx convenience binary build against latest nifi
> > use example minificpp flow
> >
> > Things look good.
> >
> > Oddity:
> > - Under 'third-party' folder there is an empty 'apache-rat' directory
> >
> > Thanks
> > Joe
> >
> > On Fri, Jun 1, 2018 at 3:43 PM, Aldrin Piri 
> wrote:
> > > +1, binding
> > >
> > > Comments:
> > > * source matched the referenced commit
> > > * L look good for the additions since 0.4.0
> > > * hashes and signature looked good
> > > * build and tests checked out in CentOS, OS X 10.13, and Ubuntu 18.04
> > > driven by bootstrap
> > > * verified functionality with some simple flows and Site to Site
> transfer
> > > to NiFi over an extended duration
> > >
> > >
> > > As a note to other reviewers, the resulting assembly will be located in
> > > your build directory as 'nifi-minifi-cpp-0.5.0-bin.tar.gz'
> > >
> > > Thanks for generating this RC, Jeremy and to all the contributors.  A
> lot
> > > of great new bits in this release.
> > >
> > > --aldrin
> > >
> > >
> > > On Fri, Jun 1, 2018 at 11:41 AM, Marc  wrote:
> > >
> > >> Jeremy,
> > >>   +1 binding
> > >>
> > >>   Thanks for generating the release!
> > >>
> > >>I verified sigs and checksums. Built on u18 and OSX.
> > >>
> > >>   I ran unit/integration tests with ctest. Also ran a simple flow with
> > >> GetFile -> LogAttribute, but also includes two controller services for
> > >> battery monitoring and network management.
> > >>
> > >>   Thanks,
> > >>   Marc
> > >>
> > >>
> > >> On Thu, May 31, 2018 at 8:39 PM, Jeremy Dyer 
> > >> wrote:
> > >> > Hello Apache NiFi Community,
> > >> >
> > >> > I am pleased to call this vote for the source release of Apache NiFi
> > >> MiNiFi
> > >> > C++, nifi-minifi-cpp-0.5.0.
> > >> >
> > >> > The source archive, signature, and digests can be located at:
> > >> >
> > >> > Source Archive:
> > >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> > >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz
> > >> >
> > >> > GPG armored signature:
> > >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> > >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.asc
> > >> >
> > >> > Source MD5:
> > >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> > >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.md5
> > >> >
> > >> > Source SHA1:
> > >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> > >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.sha1
> > >> >
> > >> > Source SHA256:
> > >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> > >> > 0.5.0/nifi-minifi-cp

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.5.0

[Tony Kurc]

All, I haven't been able to verify this release due to some equipment
failure.. it looks like there is enough votes to pass, but I'm going to
keep trying.

On Sun, Jun 3, 2018, 5:58 PM Joe Witt  wrote:

> +1 (binding)
>
> Confirmed sigs, hashes, commit.
> Built on Fedora 28
> Checked L  Wow that thing is serious!  Nicely done.
>
> Ran flow example flow on fedora 28 build against latest nifi using
> example minificpp flow
> Ran flow example on osx convenience binary build against latest nifi
> use example minificpp flow
>
> Things look good.
>
> Oddity:
> - Under 'third-party' folder there is an empty 'apache-rat' directory
>
> Thanks
> Joe
>
> On Fri, Jun 1, 2018 at 3:43 PM, Aldrin Piri  wrote:
> > +1, binding
> >
> > Comments:
> > * source matched the referenced commit
> > * L look good for the additions since 0.4.0
> > * hashes and signature looked good
> > * build and tests checked out in CentOS, OS X 10.13, and Ubuntu 18.04
> > driven by bootstrap
> > * verified functionality with some simple flows and Site to Site transfer
> > to NiFi over an extended duration
> >
> >
> > As a note to other reviewers, the resulting assembly will be located in
> > your build directory as 'nifi-minifi-cpp-0.5.0-bin.tar.gz'
> >
> > Thanks for generating this RC, Jeremy and to all the contributors.  A lot
> > of great new bits in this release.
> >
> > --aldrin
> >
> >
> > On Fri, Jun 1, 2018 at 11:41 AM, Marc  wrote:
> >
> >> Jeremy,
> >>   +1 binding
> >>
> >>   Thanks for generating the release!
> >>
> >>I verified sigs and checksums. Built on u18 and OSX.
> >>
> >>   I ran unit/integration tests with ctest. Also ran a simple flow with
> >> GetFile -> LogAttribute, but also includes two controller services for
> >> battery monitoring and network management.
> >>
> >>   Thanks,
> >>   Marc
> >>
> >>
> >> On Thu, May 31, 2018 at 8:39 PM, Jeremy Dyer 
> >> wrote:
> >> > Hello Apache NiFi Community,
> >> >
> >> > I am pleased to call this vote for the source release of Apache NiFi
> >> MiNiFi
> >> > C++, nifi-minifi-cpp-0.5.0.
> >> >
> >> > The source archive, signature, and digests can be located at:
> >> >
> >> > Source Archive:
> >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz
> >> >
> >> > GPG armored signature:
> >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.asc
> >> >
> >> > Source MD5:
> >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.md5
> >> >
> >> > Source SHA1:
> >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.sha1
> >> >
> >> > Source SHA256:
> >> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.sha256
> >> >
> >> > The Git tag is minifi-cpp-0.5.0-RC1
> >> > The Git commit hash is 5f3b3973e37def4d8ed2753837986d121fd58322
> >> > * *https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-
> >> cpp.git;a=commit;h=5f3b3973e37def4d8ed2753837986d121fd58322
> >> >  >> cpp.git;a=commit;h=5f3b3973e37def4d8ed2753837986d121fd58322>*
> >> > * *https://github.com/apache/nifi-minifi-cpp/commit/
> >> 5f3b3973e37def4d8ed2753837986d121fd58322
> >> >  >> 5f3b3973e37def4d8ed2753837986d121fd58322>*
> >> >
> >> > Checksums of nifi-minifi-cpp-0.5.0-source.tar.gz:
> >> > MD5: 9ec230b9ac3004981000276015860c52
> >> > SHA1: a9e3fe34ed25f9f1a840cd318845bcdb6fb622f1
> >> > SHA256:
> 78b5bbd65d1e3484efafc02a882f99063e06b88e1694daff6c24aaa3066037dc
> >> >
> >> > KEYS file available here:
> >> > https://dist.apache.org/repos/dist/dev/nifi/KEYS
> >> >
> >> > 87 issues were closed/resolved for this release:
> >> > *https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >> projectId=12321520=12342659
> >> >  >> projectId=12321520=12342659>*
> >> >
> >> > Release note highlights can be found here:
> >> > *https://cwiki.apache.org/confluence/display/MINIFI/
> >> Release+Notes#ReleaseNotes-Versioncpp-0.5.0
> >> >  >> Release+Notes#ReleaseNotes-Versioncpp-0.5.0>*
> >> >
> >> > The vote will close 3 June at 9PM EST.
> >> >
> >> > 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-minifi-cpp-0.4.0
> >> > [ ] +0 no opinion
> >> > [ ] -1 Do not release this package because...
> >> >
> >> > Thanks!
> >>
>

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

[Tony Kurc]

+1 (binding)

comments:
verified signature and hashes
Built on ubuntu 14.04 x86_64
Reviewed NOTICE and LICENSE files, did not find issues
Ran a few simple flows without issues.

On Thu, Apr 5, 2018 at 9:54 AM, Aldrin Piri  wrote:

> +1, binding
>
>
> comments:
>
> * signature and hashes check out
> * build/tests verified on Debian 9, OS X 10.13, & CentOS 7
> * simple flows and templates looked good
>
> On Wed, Apr 4, 2018 at 10:13 PM, Scott Aslan 
> wrote:
>
> > +1 (binding) Release this package as nifi-1.6.0
> >
> > - Ran through release helper
> > - Verified with test flow
> >
> > On Wed, Apr 4, 2018 at 5:20 PM, Bryan Bende  wrote:
> >
> > > +1 (binding) Release this package as nifi-1.6.0
> > >
> > > - Ran through release helper
> > > - Ran sample flows and tested granular restricted components with
> > > versioned flows
> > >
> > > On Wed, Apr 4, 2018 at 4:40 PM, Matt Gilman 
> > > wrote:
> > > > +1 (binding) Release this package as nifi-1.6.0
> > > >
> > > > - Ran through release help
> > > > - Verified issued discovered by Andrew Lim in previous RC
> > > >
> > > > Thanks for RMing Joe!
> > > >
> > > > Matt
> > > >
> > > > On Wed, Apr 4, 2018 at 2:01 PM, Pierre Villard <
> > > pierre.villard...@gmail.com>
> > > > wrote:
> > > >
> > > >> +1 binding
> > > >>
> > > >> - went through the release helper guide
> > > >> - full build on Mac OS X
> > > >> - confirmed that previous issues reported with RC1 and RC2 are fixed
> > > >> - tested secured/unsecured standalone/cluster deployments
> > > >>
> > > >> Minor remark for the RM documentation and the release helper guide.
> > > We're
> > > >> currently saying to run
> > > >> mvn clean install -Pcontrib-check,include-grpc
> > > >>
> > > >> I'd recommend to run all the existing "include" profiles to be on
> the
> > > safe
> > > >> side:
> > > >> mvn clean install -Pcontrib-check,include-grpc,
> > > >> include-atlas,include-ranger
> > > >>
> > > >> Pierre
> > > >>
> > > >>
> > > >>
> > > >> 2018-04-04 16:43 GMT+02:00 Marc :
> > > >>
> > > >> > +1 binding
> > > >> >
> > > >> >-- verified sigs and hashes.
> > > >> >-- confirmed a parallel build with tests
> > > >> >-- started secure cluster and interfaced with Apache NiFi
> MiNiFi
> > > C++
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Wed, Apr 4, 2018 at 6:33 AM, Takanobu Asanuma <
> > > tasan...@yahoo-corp.jp
> > > >> >
> > > >> > wrote:
> > > >> > > Thanks for all your efforts, Joe.
> > > >> > >
> > > >> > > +1(non-binding).
> > > >> > >  - Verified all hashes
> > > >> > >  - Succeeded "mvn -T 2.0C clean install -Prpm,generateArchives
> > > >> > -DskipTests"
> > > >> > >  - Started a secure cluster with three NiFi nodes and three ZK
> > nodes
> > > >> > using Docker (Verified the whitelist feature)
> > > >> > >  - Verified some dataflows work fine
> > > >> > >
> > > >> > > -Takanobu Asanuma
> > > >> > >
> > > >> > > -Original Message-
> > > >> > > From: Joe Witt [mailto:joew...@apache.org]
> > > >> > > Sent: Wednesday, April 04, 2018 8:49 AM
> > > >> > > To: dev@nifi.apache.org
> > > >> > > Subject: [VOTE] Release Apache NiFi 1.6.0 (RC3)
> > > >> > >
> > > >> > > 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-1124
> > > >> > >
> > > >> > > The Git tag is nifi-1.6.0-RC3
> > > >> > > The Git commit ID is f8466cb16d6723ddc3bf5f0e7f8ce8a47d27cbe5
> > > >> > > https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> > > >> > f8466cb16d6723ddc3bf5f0e7f8ce8a47d27cbe5
> > > >> > >
> > > >> > > Checksums of nifi-1.6.0-source-release.zip:
> > > >> > > SHA1: d1e1c24f9af809bf812982962b61d07df4f1131e
> > > >> > > SHA256: 1e5028d594bb402aa36460f1b826d4
> > > e8a664ad6f0538deed20286cbf3c62
> > > >> 1fb8
> > > >> > > SHA512: 8cb10cbafa6feeed712dbc0cf07649
> > > 6d6bc014276aab71383ff3481d8ea7
> > > >> > 19cf1f39766abc76c75ba58ffca747df3bd6d9bac82e410de1c78673dcd1
> > 6a5ddfee
> > > >> > >
> > > >> > > 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
> > > >> > >
> > > >> > > 162 issues were closed/resolved for this release:
> > > >> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > >> > projectId=12316020=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 

[ANNOUNCE] New Apache NiFi Committer Mike Thomsen

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Mike
has accepted the PMC's invitation to become a committer on the Apache NiFi
project. We greatly appreciate all of Mike's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

Mike has been contributing to the project for quite a while, contributing
features such as  enhancements to MongoDB and HBase processors as well as
things like improvements to Expression Language and LookupService. I'm sure
many of you have interacted with Mike on the mailing lists where he has
been giving great input on both the project and community. We also
appreciate his work reviewing and providing feedback on new contributions.

Welcome and congratulations!
Tony

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Tony Kurc]

Is some of the thinking that projects other than nifi projects would use
this?

On Feb 22, 2018 10:00 PM, "Scott Aslan"  wrote:

> Sivaprasanna,
>
> I am not sure I follow exactly what you are saying...
>
> NiFi Registry would no longer continue to host a copy of the FDS NgModule.
> Instead, NiFi Registry would just add the NiFi FDS sub-project as a client
> side dependency in its package.json. This would be analogous to how NiFi
> Registry depends on Angular Material, etc. npm supports the ability to
> download published packages which are current with the latest stable
> release of a package. npm *also* supports the ability to develop off
> of the *master
> branch (or any other branch really)* of the NiFi FDS. An example of this
> can be found in the github.io demo here
>  json#L45>
> . By placing that dependency in the package.json for the NiFi Registry each
> subsequent clean build would automatically download the latest master
> branch of the NiFi FDS sub-project and developers can leverages the latest
> NiFi FDS components.
>
> This also brings up a good point about release management. I have also
> included a prototype of one possible implementation of automating the
> tagging of a branch and automatically updating release version numbers etc.
> leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with the
> described grunt task.
>
> [1]
> https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile.
> js#L47
>
> [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-0.0.1-RC.0
>
> On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna 
> wrote:
>
> > I agree with Matt. With clear documentation and guides, contributions on
> > the sub-projects can be streamlined and be ensured that the necessary
> > changes are already available on the core project i.e NiFi. One challenge
> > is that the committer of the sub-project should have the courtesy to
> check
> > wether the supporting changes are made available to the core project and
> > track its status but given how contributions are being handled in
> > nifi-registry project, I don’t think it’s going to be that much of a
> > headache.
> >
> > We could also add to the helper doc mentioning that if the contribution
> is
> > going to affect a core component, the contributor needs to add the JIRA
> id
> > of the core project’s supporting changes in the sub-projects’ issue
> > description.
> >
> > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman 
> > wrote:
> >
> > > Joe, Joe,
> > >
> > > Regarding the release process... I think it could be similar to how
> folks
> > > verified and validated the NiFi Registry release. Guidance was given
> in a
> > > helper guide regarding how to obtain/build a branch or PR that
> references
> > > the new components. For the Registry release, there was a PR for NiFi
> > that
> > > had the supporting changes already available.
> > >
> > > We may have this issue any time we release new versions that depend on
> > > another (sub)project.
> > >
> > > Matt
> > >
> > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall  >
> > > wrote:
> > >
> > > > Scott,
> > > >
> > > > Definitely like the direction of standardizing NiFi and Registry
> around
> > > the
> > > > same set of components, so the user has a common UX. Is there
> precedent
> > > for
> > > > creating a new sub-project just for common components/modules to be
> > used
> > > by
> > > > the top-level, and it's other sub-projects? My concerns are similar
> to
> > > > Joe's. Along those lines, if the core problems we're trying to
> address
> > is
> > > > the release process and distribution, is there a less "heavy-weight"
> > > > avenue?
> > > >
> > > > In the past, we've also talked about pulling out the core NiFi
> > framework
> > > to
> > > > be shared between NiFi and MiNiFi-Java for similar reasons. How we go
> > > about
> > > > solving this for the UI could be used a model for the core framework
> as
> > > > well.
> > > >
> > > > - Joe
> > > >
> > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> mikerthom...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Also, what sort of framework is the UI being standardized on?
> > Angular?
> > > > > React? Something else?
> > > > >
> > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt 
> > wrote:
> > > > >
> > > > > > Scott
> > > > > >
> > > > > > Ok so extract out the fluid design work you started with NiFi
> > > Registry
> > > > > > to its own codebase which can be rev'd and published to NPM
> making
> > it
> > > > > > easier to consume/reuse across NiFi projects and offers better
> > > > > > consistency.  This sounds interesting.
> > > > > >
> > > > > > In thinking through the additional community effort or the effort
> > > > > > trade-off:
> > > > > > How often do you anticipate we'd be doing releases (and thus

Re: Will you accept contributions in Scala?

[Tony Kurc]

It is like Matt read my mind.

On Sat, Feb 10, 2018 at 6:26 PM, Matt Burgess  wrote:

> I'm fine with a vote, but I'll be voting to keep Java as the single
> language for the (non-test) code. I share the same concerns as many of
> the other folks as far as accepting other languages, it's mainly the
> "slippery slope" argument that I don't want to turn into a
> JVM-language flame war.  If Scala, why not Groovy? Certainly the
> syntax is closer to Java, and the community has accepted it as a valid
> language for writing unit tests, although we stopped short for
> allowing it for the deployable NiFi codebase, for the same reasons
> IIRC.  If Scala and/or Groovy, why not Kotlin?  The same argument
> (albeit more tenuous) goes for Clojure and just about every other JVM
> language (although I don't expect a call for LuaJ processors lol).
>
> Whether we decide to support various languages ad-hoc or not, I would
> strenuously object to multiple/hybrid build systems for the deployed
> artifacts. If I could switch NiFi completely to Gradle I would, but I
> realize there are good reasons for not doing so (yet?) in the Apache
> NiFi community, and I would never want any hybrid Maven/Gradle build
> for the deployable code, likewise for SBT, Leiningen, etc. With a
> custom Mojo for Maven NAR builds, and the complexity for hybrid builds
> in general, I think this would create a maintenance nightmare.
>
> The language thing is a tough decision though, it's not awesome that
> specifying a single language can be a barrier to a more diverse
> community, certainly Scala-based bundles would be more than welcome in
> the overall NiFi ecosystem, I just think the cons outweigh the pros
> for the baseline code. I've written Groovy processors/NARs using
> Gradle as the build system, and I'm good with keeping them in my own
> repo, especially when the Extension Registry becomes a thing. I can
> see the Extension Registry perhaps making this a moot point, but
> clearly we need to have this discussion in the meantime.
>
> Regards,
> Matt
>
>
> On Sat, Feb 10, 2018 at 5:23 PM, Andrew Grande  wrote:
> > Wasn't there a warning trigger about the NiFi distro size from Apache
> > recently? IMO, before talking alternative languages, solve the modularity
> > and NAR distribution problem. I think the implementation of a module
> won't
> > matter much then, the point being not everything has to go in the core,
> > base distribution, but can still be easily sourced from a known repo, for
> > example.
> >
> > I have a feeling NiFi 1.6+ can be approaching 2GB distro size soon :)
> >
> > Andrew
> >
> > On Sat, Feb 10, 2018, 5:12 PM Joey Frazee 
> wrote:
> >
> >> This probably necessitates a vote, yeah?
> >>
> >> Frankly, I’m usually happier writing Scala, and I’ve not encountered any
> >> problems using processors written in Scala, but I think it’ll be
> important
> >> to tread lightly.
> >>
> >> There’s a few things that pop into my head:
> >>
> >> - Maintainability and reviewability. A very very good Java developer
> need
> >> not, by definition, either know how to write or identify good Scala or
> spot
> >> problems and bugs.
> >> - Every Scala processor would either end up with a 5MB scala-lang.jar
> >> packaged into the .nar or we’d have to start including it in the core
> >> somewhere, if it’s not. It’s possible it might have already gotten
> pulled
> >> up from other dependencies.
> >> - Style. There’s a tremendous amount of variation in Scala style because
> >> of its type system, implicits, macros, and functional nature. There are
> >> very good people out there that can write good Scala that isn’t
> readable by
> >> the 99%.
> >> - Binary compatibility. Scala tends to be a little more brazen about
> >> breaking binary compatibility in major releases and those happen a bit
> more
> >> often than with Java. That’s not a problem for any potential source
> code in
> >> the project, but it could present some dependency issues someday.
> >> - Testing. There’s N > 1 test frameworks and testing styles within
> those,
> >> so there’s a lot of options for introducing more variability into the
> tests.
> >> - NiFi uses a lot of statics in setting up properties and relationships
> >> and the like, and idiomatic Scala approaches that stuff a bit
> differently,
> >> so it’ll be necessary to impose some style guidelines so there isn’t too
> >> much variation.
> >>
> >> That said, there are some things that won’t be problematic:
> >>
> >> - As mentioned, processors written in Scala do just work.
> >> - The scala-maven-plugin works just fine allowing mixed Java-Scala
> >> projects (btw, it’d probably be not super great to do mixed Java-Scala
> and
> >> mixed Maven-SBT though).
> >> - A lot of the above concerns could be addressed by having clear style
> >> guidelines.
> >>
> >> Another thing: most of the projects I see deliver separate jars for
> Scala
> >> components are delivering 

Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.4.0 RC1

[Tony Kurc]

+1 (binding)

Verified signatures and hashes. Built using helper guide on in an Ubuntu
16.04 (x86_64) docker container. Did not try the bootstrap script (it
failed when my container didn't have a working sudo, figured this was a
non-issue for most use cases and moved on) . Ran a couple very simple
flows. One thing I didn't do was run through all the options for
building... I believe I did a fairly base build. Reviewed the LICENSE and
NOTICE.



On Thu, Jan 25, 2018 at 10:51 AM, Joe Witt  wrote:

> +1 (binding)
>
> Full build/testing done on osx.  All sigs/hashes checkout.  L on
> source and binary artifacts solid.  Ran some tests flows grabbing data
> and sending to nifi via s2s based on flows created using template
> converter in minifi toolkit.
>
> Nice progress in here!!!  Thanks
>
> On Wed, Jan 24, 2018 at 1:36 AM, Aldrin Piri  wrote:
> > Hello Apache NiFi Community,
> >
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi
> > C++, nifi-minifi-cpp-0.4.0.
> >
> > The source archive, signature, and digests can be located at:
> >
> > Source Archive:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz
> >
> > GPG armored signature:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.asc
> >
> > Source MD5:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.md5
> >
> > Source SHA1:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.sha1
> >
> > Source SHA256:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.sha256
> >
> > The Git tag is minifi-cpp-0.4.0-RC1
> > The Git commit hash is c05d467758c861f38a00c6ac5f64f75d6ca0ce05
> > * https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.
> git;a=commit;h=c05d467758c861f38a00c6ac5f64f75d6ca0ce05
> > * https://github.com/apache/nifi-minifi-cpp/commit/
> c05d467758c861f38a00c6ac5f64f75d6ca0ce05
> >
> > Checksums of nifi-minifi-cpp-0.4.0-source.tar.gz:
> > MD5: 27d82a635cee3f97841eb6af01248712
> > SHA1: 3b8bb029bcca64897223f7fb27122ac9642cd92b
> > SHA256: 887879d65514ccc7ee598ba650d05f7ff56145d8462707d38b137363ea971965
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/aldrin
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/dev/nifi/KEYS
> >
> > 49 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12321520=12341641
> >
> > Release note highlights can be found here:
> > https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Versioncpp-0.4.0
> >
> > The vote will close 27 January at 12PM EST [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 nifi-minifi-cpp-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-cpp-0.4.0-rc1-close
>

Re: Apache MiNiFi C++ 0.4.0 Release Helper Guide

[Tony Kurc]

I believe

  cmake DPORTABLE=ON -DFAIL_ON_WARNINGS= ..

may be missing a "-" before the DPORTABLE


On Wed, Jan 24, 2018 at 1:36 AM, Aldrin Piri  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
>
> # Pull down nifi-minifi-cpp-0.4.0 source release artifacts for review:
>
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.asc
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.md5
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.sha1
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.4.0/nifi-minifi-cpp-0.4.0-source.tar.gz.sha256
>
> # Verify the signature
> gpg --verify nifi-minifi-cpp-0.4.0-source.tar.gz.asc
>
> # Verify the hashes (md5, sha1, sha256) match the source and what was
> provided in the vote email thread
> md5sum nifi-minifi-cpp-0.4.0-source.tar.gz
> sha1sum nifi-minifi-cpp-0.4.0-source.tar.gz
> sha256sum nifi-minifi-cpp-0.4.0-source.tar.gz
>
> # Untar nifi-minifi-cpp-0.4.0-source.tar.gz
> tar xf nifi-minifi-cpp-0.4.0-source.tar.gz
>
> # Verify the build works
>
> The 0.4.0 release introduces bootstrap script [2] which can aid in
> acquiring the correct packages, selecting which modules are desired and
> streamlining configuration and build processes.
>
> Alternatively, the previous, manual approach is also still possible.
>
> Be mindful of the pre-requisites required for the C++ version of MiNiFi,
> enumerated in the README [1]. These can vary from system to system and
> distribution,
> an example of the package listing for a recent Ubuntu release is:
>   cmake gcc g++ libcurl4-openssl-dev uuid-dev uuid libboost-all-dev
> libssl-dev doxygen libpython3-dev libbz2-dev liblzma-dev
>
> Once the required environment is established, a build with testing and
> linting can be performed via:
>
>   cd nifi-minifi-cpp-0.4.0-source
>   mkdir build
>   cd build
>   cmake DPORTABLE=ON -DFAIL_ON_WARNINGS= ..
>   make package
>   make test
>   make linter
>
> # 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 assembly
> (nifi-minifi-cpp-0.4.0-bin.tar.gz) found in your build directory
>
> # Make sure the README, NOTICE, and LICENSE are present and correct
>
> # Run the resulting convenience binary and make sure it works as expected
>
> For some additional assistance, the recent 0.4.0 release of MiNiFi Java
> includes updated
> MiNiFi Toolkit binaries [3].  This release of MiNiFi C++ provides support
> for the same
> version (3) of the config schema supported by MiNiFi Java.
>
> # Send a response to the vote thread indicating a +1, 0, -1 based on your
> findings.
>
> Thank you for your time and effort to validate the release!
>
> [1]
> https://github.com/apache/nifi-minifi-cpp/blob/
> MINIFICPP-379-RC1/README.md#system-requirements
> [2]
> https://github.com/apache/nifi-minifi-cpp/blob/
> MINIFICPP-379-RC1/README.md#bootstrapping
> [3]
> https://nifi.apache.org/minifi/download.html
>

Re: [VOTE] Release Apache NiFi MiNiFi 0.4.0 RC2

[Tony Kurc]

+1 (binding)

Build great on ubuntu 14.04. Verified signatures and hashes and clean
build. Ran some very simple flows.
Did not find any issues with NOTICE or LICENSE. Minor point for next
release is to update copyright date everywhere (it is 2017 in the NOTICE
and a few files)

On Mon, Jan 22, 2018 at 11:41 AM, Aldrin Piri  wrote:

> +1, binding
>
> Comments:
> hashes and signatures look good
> license and notice look good
> builds and tests good for respective executables and assemblies
> verified expected behavior with templates both pre- and post- 1.5 (1.1 vs
> 1.2 encodings)
>
>
> On Mon, Jan 22, 2018 at 10:11 AM, Joe Witt  wrote:
>
> > +1 binding
> >
> > Verified hashes, signature, last real commit is present, LICENSE and
> > NOTICE of source and resulting convenience binaries.
> >
> > Thanks!
> >
> > Joe
> >
> > On Mon, Jan 22, 2018 at 9:40 AM, Kevin Doran  wrote:
> > > +1, non-binding
> > >
> > > Ran through the steps in the release helper guide (using NiFi 1.5.0 for
> > integration testing) without issue.
> > >
> > > Overall, it looks like a solid release! Thanks everyone who
> contributed,
> > and thanks for handling RM duties Aldrin!
> > >
> > > Kevin
> > >
> > > On 1/18/18, 15: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: b0ee425f7c214d423f22b75aa2006d
> cdabf407cd29b0bd2c4f8a8ea3a3ec
> > 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=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: [DISCUSS] MiNiFi Releases

[Tony Kurc]

I like what you have to say

On Jan 16, 2018 9:17 AM, "Aldrin Piri"  wrote:

> Hey folks,
>
> With the release of NiFi 1.5 we have a current gap in the typical flow
> performed in taking a template with an RPG to connect from a MiNiFi
> instance to NiFi as discovered in MINIFI-421[1].
>
> NiFi adjusted the relationship of input port identifiers in remote
> processing groups which required some additional handling for newly encoded
> template versions.  I have a PR [2] that both provides this logic and
> upgrades the core libraries in MiNiFi Java to allow the config toolkit to
> provide the original workflow.
>
> I am proposing that we do a release of each of the MiNiFi implementations,
> starting with Java to generate an updated toolkit and then following with
> C++, which has updates to its config handling that will allow it to also
> make use of the same toolkit and version 3 of the schema.
>
> Once the PR has been reviewed/merged I would like to begin the release
> process for MiNiFi Java and at the conclusion of its successful release,
> begin the C++ release process.
>
> [1] https://issues.apache.org/jira/browse/MINIFI-421
> [2] https://github.com/apache/nifi-minifi/pull/109
>

Re: [DISCUSS] Apache NiFi distribution has grown too large

[Tony Kurc]

I added some more stats to the wiki page, trying to determine what
dependencies are included in jars. It seems like there is opportunity.

Highlights, 50 copies of what appears to be some version of bcprov-jdk15
for a total of 162M. 51 copies of jackson-databind.

total size   copies  jar
 30.97MB 65 META-INF/bundled-dependencies/commons-lang3-XXX.jar
 32.53MB 50 META-INF/bundled-dependencies/bcpkix-jdk15on-XXX.jar
 33.55MB 16 META-INF/bundled-dependencies/guava-XXX.jar
 39.62MB  1 META-INF/bundled-dependencies/jython-shaded-XXX.jar
 63.06MB 51
 META-INF/bundled-dependencies/jackson-databind-XXX.jar
162.07MB 50 META-INF/bundled-dependencies/bcprov-jdk15on-XXX.jar


On Sat, Jan 13, 2018 at 2:09 PM, Joey Frazee <joey.fra...@icloud.com> wrote:

> I tend to have feelings similar to Michael about a multi-repo approach.
> I’ve rarely seen it help and more often seen it hurt — it’s confusing
> (especially to newcomers), stuff gets neglected because it’s easier to
> ignore, you need another master project or some such to do an entire build.
>
> Maybe git submodules could help mitigate this, but creating independent
> assemblies or using different build profiles to enable building and
> packaging the binaries in different ways would satisfy everything except
> disentangling the releases.
>
> -joey
>
> On Jan 13, 2018, 12:40 PM -0600, Brandon DeVries <b...@jhu.edu>, wrote:
> > I agree... Long term extension registry, short term one repo with
> different
> > assemblies (e.g. standard, slim, analytic, etc...).
> >
> > Brandon
> >
> > On Sat, Jan 13, 2018 at 1:35 PM Pierre Villard <
> pierre.villard...@gmail.com
> > wrote:
> >
> > > Option #3 also has my preference. But it's probably a good idea to only
> > > keep one git repo and play with the assembly and Maven profiles for the
> > > releases, no? It'd be certainly easier for release management process.
> But
> > > this decision could also depend on how the option #3 is going to be
> > > implemented I guess.
> > >
> > > 2018-01-13 6:36 GMT-07:00 Joe Witt <joe.w...@gmail.com>:
> > >
> > > > thanks tony!
> > > >
> > > > On Jan 12, 2018 10:48 PM, "Tony Kurc" <trk...@gmail.com> wrote:
> > > >
> > > > > I put some of the data I was working with on the wiki -
> > > > >
> > > > > https://cwiki.apache.org/confluence/display/NIFI/NiFi+
> 1.5.0+nar+files
> > > > >
> > > > > On Fri, Jan 12, 2018 at 10:28 PM, Jeremy Dyer <jdy...@gmail.com
> > > wrote:
> > > > >
> > > > > > So my favorite option is Bryan’s option number “three” of using
> the
> > > > > > extension registry. Now my thought is do we really need to add
> > > > complexity
> > > > > > and do anything in the mean time or just focus on that? Meaning
> we
> > > have
> > > > > > roughly 500mb of available capacity today so why don’t we spend
> those
> > > > man
> > > > > > hours we would spend on getting the second repo up on the
> extension
> > > > > > registry instead?
> > > > > >
> > > > > > @Bryan do you have thoughts about the deployment of those bars
> in the
> > > > > > extension registry? Since we won’t be able to build the release
> > > binary
> > > > > > anymore would we still need to create separate repos for the
> nars or
> > > > > no?? I
> > > > > > have used the registry a little but I’m not 100% sure on your
> vision
> > > > for
> > > > > > the nars
> > > > > >
> > > > > > - Jeremy Dyer
> > > > > >
> > > > > > Sent from my iPhone
> > > > > >
> > > > > > > On Jan 12, 2018, at 10:18 PM, Tony Kurc <tk...@apache.org>
> wrote:
> > > > > > >
> > > > > > > I was looking at nar sizes, and thought some data may be
> helpful. I
> > > > > used
> > > > > > my recent RC1 verification as a basis for getting file sizes, and
> > > just
> > > > > got
> > > > > > the file size for each file in the assembly named "*.nar". I
> don't
> > > know
> > > > > > whether the images I pasted in will go through, but I made some
> > > > graphs.b
> > > > > > The first is a histogram of nar file size in buckets o

Re: [DISCUSS] Apache NiFi distribution has grown too large

[Tony Kurc]

I put some of the data I was working with on the wiki -

https://cwiki.apache.org/confluence/display/NIFI/NiFi+1.5.0+nar+files

On Fri, Jan 12, 2018 at 10:28 PM, Jeremy Dyer <jdy...@gmail.com> wrote:

> So my favorite option is Bryan’s option number “three” of using the
> extension registry. Now my thought is do we really need to add complexity
> and do anything in the mean time or just focus on that? Meaning we have
> roughly 500mb of available capacity today so why don’t we spend those man
> hours we would spend on getting the second repo up on the extension
> registry instead?
>
> @Bryan do you have thoughts about the deployment of those bars in the
> extension registry? Since we won’t be able to build the release binary
> anymore would we still need to create separate repos for the nars or no?? I
> have used the registry a little but I’m not 100% sure on your vision for
> the nars
>
> - Jeremy Dyer
>
> Sent from my iPhone
>
> > On Jan 12, 2018, at 10:18 PM, Tony Kurc <tk...@apache.org> wrote:
> >
> > I was looking at nar sizes, and thought some data may be helpful. I used
> my recent RC1 verification as a basis for getting file sizes, and just got
> the file size for each file in the assembly named "*.nar". I don't know
> whether the images I pasted in will go through, but I made some graphs.b
> The first is a histogram of nar file size in buckets of 10MB. The second
> basically is similar to a cumulative distribution, the x axis is the "rank"
> of the nar (smallest to largest), and the y-axis is how what fraction of
> the all the sizes of the nars together are that rank or lower. In other
> words, on the graph, the dot at 60 and ~27 means that the smallest 60 nars
> contribute only ~27% of the total. Of note, the standard and framework nars
> are at 83 and 84.
> >
> >
> >
> >
> >
> >> On Fri, Jan 12, 2018 at 5:04 PM, Michael Moser <moser...@gmail.com>
> wrote:
> >> And of course, as I hit  I thought of one more thing.
> >>
> >> We could keep all of the code in 1 git repo (1 project) but the
> >> nifi-assembly part of the build could be broken up to build core NiFi
> >> separately from the tar/zip functional grouping of other NARs.
> >>
> >> On Fri, Jan 12, 2018 at 5:01 PM, Michael Moser <moser...@gmail.com>
> wrote:
> >>
> >> > Long term I would also like to see #3 be the solution.  I think what
> >> > Joseph N described could be part of the capabilities of #3.
> >> >
> >> > I would like to add a note of caution with respect to reorganizing and
> >> > releasing extension bundles separately:
> >> >
> >> >- the burden on release manager expands because many more projects
> >> >have to be released; probably not all on each release cycle but it
> could
> >> >still be many
> >> >- the chance of accidentally forgetting to release a project in a
> >> >release cycle becomes non-zero
> >> >- sharing code between projects gets a bit harder because you have
> to
> >> >manage releasing projects in a specific order
> >> >- it becomes harder to find all of the projects that need to change
> >> >when shared code is added
> >> >- the simple act of finding code becomes harder ... in which
> project
> >> >is that class in? (IDEs like IntelliJ can search in 1 project, but
> if they
> >> >search across multiple projects, then I haven't learned how)
> >> >
> >> > I used to maintain several nars in separate projects, and recently
> >> > reorganized them into 1 project (following NiFi's multi-module maven
> build)
> >> > and life has become much easier!
> >> >
> >> > -- Mike
> >> >
> >> >
> >> >
> >> > On Fri, Jan 12, 2018 at 4:33 PM, Chris Herrera <
> chris.herrer...@gmail.com>
> >> > wrote:
> >> >
> >> >> I very much like the solution proposed by Bryan below. This would
> allow
> >> >> for a cleaner docker image as well, while still proving the
> functionality
> >> >> as needed. For sure, the extension registry will be great, but in
> the mean
> >> >> time this is an adequate mid step.
> >> >>
> >> >> Regards,
> >> >> Chris
> >> >>
> >> >> On Jan 12, 2018, 2:52 PM -0600, Bryan Bende <bbe...@gmail.com>,
> wrote:
> >> >> > Long term I'd like to see the extension regis

Re: [DISCUSS] Apache NiFi distribution has grown too large

[Tony Kurc]

I was looking at nar sizes, and thought some data may be helpful. I used my
recent RC1 verification as a basis for getting file sizes, and just got the
file size for each file in the assembly named "*.nar". I don't know whether
the images I pasted in will go through, but I made some graphs.b The first
is a histogram of nar file size in buckets of 10MB. The second basically is
similar to a cumulative distribution, the x axis is the "rank" of the nar
(smallest to largest), and the y-axis is how what fraction of the all the
sizes of the nars together are that rank or lower. In other words, on the
graph, the dot at 60 and ~27 means that the smallest 60 nars contribute
only ~27% of the total. Of note, the standard and framework nars are at 83
and 84.


[image: Inline image 3]
[image: Inline image 4]

On Fri, Jan 12, 2018 at 5:04 PM, Michael Moser  wrote:

> And of course, as I hit  I thought of one more thing.
>
> We could keep all of the code in 1 git repo (1 project) but the
> nifi-assembly part of the build could be broken up to build core NiFi
> separately from the tar/zip functional grouping of other NARs.
>
> On Fri, Jan 12, 2018 at 5:01 PM, Michael Moser  wrote:
>
> > Long term I would also like to see #3 be the solution.  I think what
> > Joseph N described could be part of the capabilities of #3.
> >
> > I would like to add a note of caution with respect to reorganizing and
> > releasing extension bundles separately:
> >
> >- the burden on release manager expands because many more projects
> >have to be released; probably not all on each release cycle but it
> could
> >still be many
> >- the chance of accidentally forgetting to release a project in a
> >release cycle becomes non-zero
> >- sharing code between projects gets a bit harder because you have to
> >manage releasing projects in a specific order
> >- it becomes harder to find all of the projects that need to change
> >when shared code is added
> >- the simple act of finding code becomes harder ... in which project
> >is that class in? (IDEs like IntelliJ can search in 1 project, but if
> they
> >search across multiple projects, then I haven't learned how)
> >
> > I used to maintain several nars in separate projects, and recently
> > reorganized them into 1 project (following NiFi's multi-module maven
> build)
> > and life has become much easier!
> >
> > -- Mike
> >
> >
> >
> > On Fri, Jan 12, 2018 at 4:33 PM, Chris Herrera <
> chris.herrer...@gmail.com>
> > wrote:
> >
> >> I very much like the solution proposed by Bryan below. This would allow
> >> for a cleaner docker image as well, while still proving the
> functionality
> >> as needed. For sure, the extension registry will be great, but in the
> mean
> >> time this is an adequate mid step.
> >>
> >> Regards,
> >> Chris
> >>
> >> On Jan 12, 2018, 2:52 PM -0600, Bryan Bende , wrote:
> >> > Long term I'd like to see the extension registry take form and have
> >> > that be the solution (#3).
> >> >
> >> > In the more near term, we could separate all of the NARs, except for
> >> > framework and maybe standard processors & services, into a separate
> >> > git repo.
> >> >
> >> > In that new git repo we could organize things like Joe N just
> >> > described according to some kind of functional grouping. Each of these
> >> > functional bundles could produce its own tar/zip which we can make
> >> > available for download.
> >> >
> >> > That would separate the release cycles between core NiFi and the other
> >> > NARs, and also avoid having any single binary artifact that gets too
> >> > large.
> >> >
> >> >
> >> >
> >> > On Fri, Jan 12, 2018 at 3:43 PM, Joseph Niemiec  >
> >> wrote:
> >> > > just a random thought.
> >> > >
> >> > > Drop In Lib packs... All the Hadoop ones in one package for example
> >> that
> >> > > can be added to a slim Nifi install. Another may be for Cloud, or
> >> Database
> >> > > Interactions, Integration (JMS, FTP, etc) of course defining these
> >> groups
> >> > > would be the tricky part... Or perhaps some type of installer which
> >> allows
> >> > > you to elect which packages to download to add to the slim install?
> >> > >
> >> > >
> >> > > On Fri, Jan 12, 2018 at 3:10 PM, Joe Witt 
> wrote:
> >> > >
> >> > > > Team,
> >> > > >
> >> > > > The NiFi convenience binary (tar.gz/zip) size has grown to 1.1GB
> now
> >> > > > in the latest release. Apache infra expanded it to 1.6GB allowance
> >> > > > for us but has stated this is the last time.
> >> > > > https://issues.apache.org/jira/browse/INFRA-15816
> >> > > >
> >> > > > We need consider:
> >> > > > 1) removing old nars/less commonly used nars/or particularly
> massive
> >> > > > nars from the assembly we distribute by default. Folks can still
> use
> >> > > > these things if they want just not from our convenience binary
> >> > > > 2) collapsing nars with highly repeating 

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

[Tony Kurc]

+1 (binding)

verified signature and hashes. built clean with contrib-check. ran some
simple flows without issue. reviewed the NOTICE and LICENSE, saw no issues.

On Wed, Jan 10, 2018 at 9:05 PM, Koji Kawamura 
wrote:

> +1 (binding) Release this package as nifi-1.5.0
>
> Verified signature and hashes. Built with include-atlas profile.
> mvn clean install -Pcontrib-check,include-grpc,include-atlas
> Confirmed flows using NiFi Registry and ReportLineageToAtlas reporting
> task, worked as expected.
>
> On Thu, Jan 11, 2018 at 4:35 AM, Matt Gilman 
> wrote:
> > +1 (binding) Release this package as nifi-1.5.0
> >
> > Verified signature, hashes, build, etc. Ran through a number of scenarios
> > with Apache NiFi Registry 0.1.0 and everything is working as expected.
> >
> > Thanks Joe for RMing this release!
> >
> > Matt
> >
> > On Wed, Jan 10, 2018 at 2:22 PM, Rob Moran  wrote:
> >
> >> +1, non-binding
> >>
> >> * All looks good/in place following the release helper
> >> * Reviewed help docs related to new Registry integration
> >> * Connected a registry client and did some quick testing of basic
> version
> >> control related actions
> >>
> >>
> >> On Wed, Jan 10, 2018 at 1:24 PM Andrew Lim 
> >> wrote:
> >>
> >> > +1 (non-binding)
> >> >
> >> > -Ran full clean install on OS X (10.11.6)
> >> > -Tested integration with NiFi Registry
> >> > -Ran record reader/writer flows
> >> > -Reviewed resolved “Core UI” component Jiras and spot checked
> inclusion
> >> in
> >> > build
> >> > -Reviewed documentation
> >> >
> >> > Drew
> >> >
> >> >
> >> > > On 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: 40b155c4911414907835f2eb0d5a4d
> a798935f27f1e5134218d904fe6c94
> >> 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=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...
> >> >
> >> >
> >>
> >> --
> >> Rob
> >>
>

Re: [DRAFT][REPORT] Apache NiFi Board Report Jan 2018

[Tony Kurc]

Looks great! Thanks for pulling this together, Joe!

On Jan 9, 2018 12:40 PM, "Joe Witt"  wrote:

> Thanks for the prompt replies all.  Board Report for Jan submitted.
>
> ## Description:
>  - Apache NiFi is an easy to use, powerful, and reliable system to
>process and distribute data.
>  - Apache NiFi MiNiFi is an edge data collection agent built to seamlessly
>integrate with and leverage the command and control of NiFi. There are
>both Java and C++ implementations.
>  - Apache NiFi Registry is a centralized registry for key configuration
> items
>including flow versions, assets, and extensions for Apache NiFi
>and Apache MiNiFi.
>  - Apache NiFi Nar Maven Plugin is a release artifact used for supporting
>the NiFi classloader isolation model.
>
> ## Issues:
>  - There are no issues requiring board attention at this time.
>
> ## Activity:
>  - Conducted several releases including Apache NiFi Registry,
>Apache NiFi MiNiFi CPP and Apache NiFi MiNiFi Java. The Apache NiFi
> Registry
>release is a very important step forward for the community as it
> provides a
>powerful software development lifecycle mechanism for Apache NiFi users
> and
>answers a long standing request and often discussed capability.
>  - Apache NiFi 1.5.0 Release Candidate under vote at the time of this board
>report writing.
>  - Voted a significant number of new committers and PMC members and are
>extremely fortunate to see strong committer pipeline continue through
> newer
>contributors with significant contributions.
>  - The PMC has identified and worked with Trademarks/Legal at Apache for a
>couple of potential trademark or licensing abuse issues.  Consensus was
> that
>neither issue rises to the level of requiring any specific official
> response
>though in one case we intend to provide a courtesy notification to a
>commercial entity that is heavily leverage Apache NiFi source code
> without
>any attribution.  It is more of a poor form issue than a real problem.
>Thanks to several highly experienced Apache Members who helped discuss
> the
>threads in detail.
>
> ## Health report:
>  - Health of the community remains strong. Mailing list and JIRA activity
> is
>consistent. ASF Hipchat is serving as an on-ramp for new users to our
>mailing list and JIRA systems. We continue to see new users and
>contributors.
>  - The PMC continues to demonstrate ability to detect and handle potential
>trademark issues though it needs to focus better on staying tight and
> prompt
>on security matters all the way through resolution.
>  - As we called out in our previous report we anticipated significant
>recognition of earned meritocracy within the committer and PMC ranks.
> That
>held true and the pipeline remains encouraging.
>
> ## PMC changes:
>
>  - Currently 26 PMC members.
>  - New PMC members:
> - Marc Parisi was added to the PMC on Wed Dec 13 2017
> - Jeff Storck was added to the PMC on Mon Dec 04 2017
> - Scott Aslan was added to the PMC on Fri Dec 01 2017
> - Michael W Moser was added to the PMC on Sun Nov 19 2017
>  - Last PMC member added Wed Dec 13 2017.
>
> ## Committer base changes:
>
>  - Currently 38 committers.
>  - New commmitters:
> - Kevin Doran was added as a committer on Wed Jan 03 2018
> - Andrew Ian Christianson was added as a committer on Mon Nov 13 2017
> - Mike Hogue was added as a committer on Thu Nov 09 2017
> - Peter Wicks was added as a committer on Thu Nov 09 2017
>  - Last committer added Wed Jan 03 2018.
>
> ## Releases:
>
>  - Apache NiFi Registry 0.1.0 was released Jan 1 2018.
>  - Apache NiFi MiNiFi Java 0.3.0 was released Dec 22 2017.
>  - Apache NiFi MiNiFi CPP 0.3.0 was released Nov 30 2017.
>
> ## Mailing list activity:
>
>  - Activity on the mailing lists remains high with a mixture
>of new users, contributors, and deeper more experienced users and
>contributors sparking discussion and questions and filing bugs or
>new features.
>
>  - us...@nifi.apache.org:
> - 581 subscribers (up 25 in the last 3 months):
> - 783 emails sent to list (721 in previous quarter)
>
>  - dev@nifi.apache.org:
> - 388 subscribers (up 5 in the last 3 months):
> - 679 emails sent to list (590 in previous quarter)
>
>  - iss...@nifi.apache.org:
> - 46 subscribers (up 0 in the last 3 months):
> - 6950 emails sent to list (5388 in previous quarter)
>
>
> ## JIRA activity:
>
>  - 356 JIRA tickets created in the last 3 months
>  - 276 JIRA tickets closed/resolved in the last 3 months
>
> On Tue, Jan 9, 2018 at 9:57 AM, Andrew Lim 
> wrote:
> > +1 LGTM
> >
> > -Drew
> >
> >> On Jan 9, 2018, at 2:15 AM, Joe Witt  wrote:
> >>
> >> Team,
> >>
> >> It is that time again to send in our board report.  I'll submit it
> >> tomorrow but would appreciate if you can take a quick look and point
> >> out things 

Re: [ANNOUNCE] New Apache NiFi Committer Kevin Doran

[Tony Kurc]

Congratulations Kevin!

On Jan 3, 2018 9:17 AM, "Bryan Bende"  wrote:

> On behalf of the Apache NiFi PMC, I am very pleased to announce that
> Kevin Doran has accepted the PMC's invitation to become a committer on
> the Apache NiFi project. We greatly appreciate all of Kevin's hard
> work and generous contributions to the project. We look forward to his
> continued involvement in the project.
>
> Kevin has made significant contributions to the NiFi Registry project,
> especially around setting up the security model & REST APIs, and was a
> major contributor to getting the first release out. You also may have
> interacted with him on the mailing lists already, as he is always
> willing to dig into questions/issues and help out.
>
> Welcome and congratulations!
>

[ANNOUNCE] New NiFi PMC member Jeff Storck

[Tony Kurc]

NiFi community,
On behalf of the Apache NiFi PMC, I am pleased to announce that Jeff Storck
has accepted the PMC's invitation to join the Apache NiFi PMC.  We greatly
appreciate all of Jeff's hard work and generous contributions to the
project. We look forward to continued involvement in the project.

For those of you enjoying NiFi 1.4.0 release, Jeff was the release manager,
which is a huge complicated set of work. He's also been a long time
contributor, committer, and a strong member of the community.

Congratulations and welcome, Jeff!

Tony

[ANNOUNCE] New NiFi PMC member Scott Aslan

[Tony Kurc]

NiFi community,
On behalf of the Apache NiFi PMC, I am pleased to announce that Scott Aslan
has accepted the PMC's invitation to join the Apache NiFi PMC.  We greatly
appreciate all of Scotts's hard work and generous contributions to the
project. We look forward to continued involvement in the project.

Scott has been delivering as a strong committer for quite a long time, is
making huge progress on nifi-registry, and has had wide reach to the
community in many ways, to include our mailing lists.

Congratulations and welcome, Scott!

Tony

Re: [ANNOUNCE] Apache NiFi MiNiFi C++ 0.3.0 release.

[Tony Kurc]

Marc et al.,
Exciting news! Great job pulling together the release!

Tony

On Fri, Dec 1, 2017 at 12:56 PM, Marc  wrote:

> Hello!
>
> The Apache NiFi team would like to announce the release of Apache NiFi -
> MiNiFi C++ 0.3.0.
>
> MiNiFi is a subproject of Apache NiFi. Apache NiFi supports powerful and
> scalable directed graphs of data routing, transformation, and system
> mediation logic . MiNiFi provides a complementary data collection approach
> that
> supplements the core tenets of NiFi in dataflow management, focusing on the
> collection of data at the source of its creation.
>
> MiNFI was developed with the following goals:
>
>- Small size and low resource consumption
>- Central management of agents
>- Generation of data provenance (full chain of custody of information)
>- Integration with NiFi for follow-on dataflow management
>
>
> This MiNiFi C++ release delivers several new processors and features.
> Please visit our release notes, below, for more information on these
> exciting changes.
>
> More details on Apache NiFi MiNiFi can be found here:
> https://nifi.apache.org/minifi
>
> The release artifacts can be downloaded from here:
> https://nifi.apache.org/minifi/download.html
>
> Issues closed/resolved for this list can be found here:
> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12321520=12341640
>  projectId=12321520=12341640>*
>
> Release note highlights can be found here:
> *https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Versioncpp-0.3.0
>  Release+Notes#ReleaseNotes-Versioncpp-0.3.0>*
>
> Thank you!
> The Apache NiFi team
>

Re: [VOTE] Release Apache NiFi MiNiFI C++ 0.3.0 (RC2)

[Tony Kurc]

+1

Built fine, ran a few simple flows. Reviewed license and notice and didn't
see any issues.

On Wed, Nov 29, 2017 at 10:36 PM, Joe Witt  wrote:

> +1 binding
>
> L looks good on both source and binary artifacts.  Ran a fairly high
> speed and stable flow of data into Kafka.  Error handling scenarios
> checked out really nicely.
>
> Found and reported
> https://issues.apache.org/jira/browse/MINIFICPP-336
>
> On Wed, Nov 29, 2017 at 6:07 PM, Kevin Doran 
> wrote:
> > +1, non-binding.
> >
> > Verified hashes and signature; did full build with docker-verify and ran
> with a sample config flow.
> >
> > On 11/27/17, 11:59, "Marc"  wrote:
> >
> > Hello Apache NiFi Community,
> >
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi
> > C++, nifi-minifi-cpp-0.3.0.
> >
> > The source archive, signature, and digests can be located at:
> >
> > Source Archive:
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz
> > GPG armored signature:
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.asc
> > Source MD5:
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.md5
> > Source SHA1:
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha1
> > Source SHA256:
> >
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha256
> >
> > The Git tag is minifi-cpp-0.3.0-RC2
> > The Git commit hash is 0e4ce79b78cbc9c89189eabb8042749a873d9723
> > *
> > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.
> git;a=commit;h=0e4ce79b78cbc9c89189eabb8042749a873d9723
> > *
> > https://github.com/apache/nifi-minifi-cpp/commit/
> 0e4ce79b78cbc9c89189eabb8042749a873d9723
> >
> > Checksums of nifi-minifi-cpp-0.3.0-source.tar.gz:
> > MD5: aeb800c4bc8829fe8af300e75d2cd15b
> > SHA1: 6dbc094ba876c7120ceb6a96d19ae8d37c62d662
> > SHA256: 1fffb6697c3cff6dd4b9ceb7c91a575df149acd160315aeb9c8a55f20d15
> 9372
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/phrocker
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/dev/nifi/KEYS
> >
> > 61 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12321520=12341640
> >
> > Release note highlights can be found here:
> > https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Versioncpp-0.3.0
> >
> > The vote will be open for 72 hours and will close 30 Nov at 12PM EDT
> [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 nifi-minifi-cpp-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-cpp-0.3.0-rc2-close
> >
> >
> >
>

Re: [VOTE] Release Apache NiFi MiNiFI C++ 0.3.0 (RC1)

[Tony Kurc]

Question about the LICENSE. When swapping in rocksdb for leveldb [1], the
leveldb LICENSE section was removed. I looked at the ticket chatter [2] and
saw "Not including RocksDB because
it is dual licensed under Apache License, Version2.0". In reviewing the
rocksdb thirdparty, it has a LICENSE.leveldb file [2], which says the code
includes "Leveldb licensed" code . I tried poking around, and it looks like
there has been a lot of discussion about rocksdb licensing, and saw a few
unceremonious commits / PRs. Digging further, I found this LEGAL ticket
[6], which I honestly can't tell what it implies, but I can't tell what
happened with this comment [7].

Did this already get discussed and I missed it somehow? Two questions,
Should the leveldb license section be re-added to our base LICENSE, and
secondly, should we look more closely at that LEGAL ticket decision, or is
the version we pulled not applicable to that discussion?

1. https://github.com/apache/nifi-minifi-cpp/commit/
488677321cdf32c196fdaae6fb31a2b38ef10461#diff-9879d6db96fd29134fc802214163b9
5a
2. https://issues.apache.org/jira/browse/MINIFICPP-113
3. https://github.com/apache/nifi-minifi-cpp/blob/minifi-
cpp-0.3.0-RC1/thirdparty/rocksdb/LICENSE.leveldb
4. https://github.com/facebook/rocksdb/commit/4a2e4891fe4c6f66fb9e8e2d29b04f
46ee702b52
5. https://github.com/facebook/rocksdb/pull/2591
6. https://issues.apache.org/jira/browse/LEGAL-303
7.
https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16109870=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16109870




On Wed, Nov 22, 2017 at 10:18 PM, Kevin Doran 
wrote:

> +1 (non-binding)
>
> Verified hashes, built and ran all tests, built docker and ran all
> integration tests. Ran a simple test flow.
>
> I did run into one minor issue, which is if virtualenv is configured with
> python3 by default then creating the virtual environment for the pytest
> integration tests fails. As this only affects integration tests in some
> environments, and not the library or agent, I don't think it is a concern
> for the purpose of the RC vote.  It's an easy fix as well... I opened
> MINIFICPP-318 [1] and submitted a PR [2].
>
> Thanks to everyone who has contributed the many features and improvements
> since the last release, and thanks Marc for pulling the RC together!
>
> [1] https://issues.apache.org/jira/browse/MINIFICPP-318
> [2] https://github.com/apache/nifi-minifi-cpp/pull/204
>
> Thanks,
> Kevin
>
> On 11/22/17, 18:42, "Aldrin Piri"  wrote:
>
> +1, binding
>
> Built, tested, and created Docker container on OS X 10.12 and Centos
> 7.3
>
> Ran a few flows and verified expected functionality on both systems.
>
> Thanks for getting this RC together!
>
> On Wed, Nov 22, 2017 at 10:49 AM, Jeremy Dyer 
> wrote:
>
> > Your right let’s not put out another release for this since it can be
> > simply fixed by using the flags you provided. I went through the
> build
> > again and validated the runtime. Everything looks good now so I’m
> changing
> > my vote to a
> >
> > +1
> >
> > - Jeremy
> >
> > > On Nov 22, 2017, at 10:31 AM, Marc  wrote:
> > >
> > > Jeremy,
> > >  Thanks for your vote.
> > >
> > >  Your version of GCC will likely cause this warnings due to spec
> > > additions, and since RocksDB fails on any warning your build
> failed as
> > well.
> > >
> > >  Please try the following before running make: *cmake -DPORTABLE=ON
> > > -DFAIL_ON_WARNINGS= ..*
> > >
> > >  I am not in favor of upgrading the version of RocksDB before
> another RC
> > > to address the issue, if it does ( there are others to address as
> well ).
> > > RocksDB created another release which I think may address this
> particular
> > > warning, but others may cause the build to fail. In some cases
> these
> > > warnings are simply to address potential performance issues.
> > >
> > >  In regards to your -1, I'm happy to put out another RC that
> hardcodes
> > the
> > > option* -DFAIL_ON_WARNINGS= *, effectively disabling the failure,
> but I'm
> > > on the fence about that. Should I simply augment the procedures?
> Would
> > love
> > > input.
> > >
> > >  Upgrading RocksDB introduces risk too, of course. The previous
> plan was
> > > to merge an updated PR for RocksDB shortly after this release to
> avoid
> > > incurring additional risk for 0.3.0.
> > >
> > >  Thanks,
> > >  Marc
> > >
> > >
> > >
> > >> On Wed, Nov 22, 2017 at 9:09 AM, Jeremy Dyer 
> wrote:
> > >>
> > >> -1 Marc I'm having trouble getting this to build using Ubuntu
> 17.10 with
> > >> GCC version "gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0" seems to be an
> issue
> > with
> > >> building RocksDB with this version of GCC. Looks like 

Re: Apache MiNiFi C++ 0.3.0 Release Helper Guide

[Tony Kurc]

Thanks, I narrowed it down to not having libbz2 for that failure, liblzma
will save me another round of building.


On Wed, Nov 22, 2017 at 5:08 PM, Marc <phroc...@apache.org> wrote:

> Tony,
>   I hit send before adding the full commands.
>
>   sudo apt-get install libbz2-dev liblzma-dev .
>
>   That would make the command in the helper guide:
>
>sudo apt-get  cmake gcc g++ libcurl4-openssl-dev uuid-dev uuid
> libboost-all-dev libssl-dev doxygen libpython3-dev libbz2-dev liblzma-dev .
>
>Let me know if that helps and apologies for the omission.
>
>   Thanks,
>Marc
>
> On Wed, Nov 22, 2017 at 5:06 PM, Marc P. <marc.par...@gmail.com> wrote:
>
> > Tony,
> >   Try adding libbz2-dev liblzma-dev to your distro if you haven't
> already.
> > I don't think I correctly copied the command for apt-get. My apologies.
> >
> > On Wed, Nov 22, 2017 at 4:26 PM, Tony Kurc <trk...@gmail.com> wrote:
> >
> >> I'm having a bit of trouble with running make test - still diagnosing,
> but
> >> it is a segfault. (building on an ubuntu 16.04 docker image).
> >>
> >> 
> >> ---
> >> CompressFileBZip
> >> 
> >> ---
> >> /nifi-minifi-cpp-0.3.0-source/libminifi/test/archive-tests/C
> >> ompressContentTests.cpp:295
> >> 
> >> ...
> >>
> >> /nifi-minifi-cpp-0.3.0-source/libminifi/test/archive-tests/C
> >> ompressContentTests.cpp:295:
> >> FAILED:
> >>   {Unknown expression after the reported line}
> >> due to a fatal error condition:
> >>   SIGSEGV - Segmentation violation signal
> >>
> >>
> >> On Tue, Nov 21, 2017 at 3:07 PM, Marc <phroc...@apache.org> 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
> >> >
> >> > # Pull down nifi-minifi-cpp-0.3.0 source release artifacts for review:
> >> >
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.asc
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.md5
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha1
> >> > wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> >> > 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha256
> >> >
> >> > # Verify the signature
> >> > gpg --verify nifi-minifi-cpp-0.3.0-source.tar.gz.asc
> >> >
> >> > # Verify the hashes (md5, sha1, sha256) match the source and what was
> >> > provided in the vote email thread
> >> > md5sum nifi-minifi-cpp-0.3.0-source.tar.gz
> >> > sha1sum nifi-minifi-cpp-0.3.0-source.tar.gz
> >> > sha256sum nifi-minifi-cpp-0.3.0-source.tar.gz
> >> >
> >> > # Untar nifi-minifi-cpp-0.3.0-source.tar.gz
> >> > tar xf nifi-minifi-cpp-0.3.0-source.tar.gz
> >> >
> >> > # Verify the build works
> >> >
> >> > Be mindful of the pre-requisites required for the C++ version of
> MiNiFi,
> >> > enumerated in the README [1] and the switching to the CMake build
> system
> >> > These can vary from system to system and distribution, an example of
> the
> >> > package listing for a recent Ubuntu release is:
> >> >   cmake gcc g++ libcurl4-openssl-dev uuid-dev uuid libboost-all-dev
> >> > libssl-dev doxygen libpython3-dev
> >> >
> >> > Once the required environment is established, a build with testing and
> >> > linting can be performed via:
> >> >
> >> >   cd nifi-minifi-cpp-0.3.0-source
> >> >   mkdir build
> >> >   cd build
> >> >   cmake ..
> >

Re: Apache MiNiFi C++ 0.3.0 Release Helper Guide

[Tony Kurc]

I'm having a bit of trouble with running make test - still diagnosing, but
it is a segfault. (building on an ubuntu 16.04 docker image).

---
CompressFileBZip
---
/nifi-minifi-cpp-0.3.0-source/libminifi/test/archive-tests/CompressContentTests.cpp:295
...

/nifi-minifi-cpp-0.3.0-source/libminifi/test/archive-tests/CompressContentTests.cpp:295:
FAILED:
  {Unknown expression after the reported line}
due to a fatal error condition:
  SIGSEGV - Segmentation violation signal


On Tue, Nov 21, 2017 at 3:07 PM, Marc  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
>
> # Pull down nifi-minifi-cpp-0.3.0 source release artifacts for review:
>
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.asc
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.md5
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha1
> wget https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/
> 0.3.0/nifi-minifi-cpp-0.3.0-source.tar.gz.sha256
>
> # Verify the signature
> gpg --verify nifi-minifi-cpp-0.3.0-source.tar.gz.asc
>
> # Verify the hashes (md5, sha1, sha256) match the source and what was
> provided in the vote email thread
> md5sum nifi-minifi-cpp-0.3.0-source.tar.gz
> sha1sum nifi-minifi-cpp-0.3.0-source.tar.gz
> sha256sum nifi-minifi-cpp-0.3.0-source.tar.gz
>
> # Untar nifi-minifi-cpp-0.3.0-source.tar.gz
> tar xf nifi-minifi-cpp-0.3.0-source.tar.gz
>
> # Verify the build works
>
> Be mindful of the pre-requisites required for the C++ version of MiNiFi,
> enumerated in the README [1] and the switching to the CMake build system
> These can vary from system to system and distribution, an example of the
> package listing for a recent Ubuntu release is:
>   cmake gcc g++ libcurl4-openssl-dev uuid-dev uuid libboost-all-dev
> libssl-dev doxygen libpython3-dev
>
> Once the required environment is established, a build with testing and
> linting can be performed via:
>
>   cd nifi-minifi-cpp-0.3.0-source
>   mkdir build
>   cd build
>   cmake ..
>   make package
>   make test
>   make linter
>
> # 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 assembly (nifi-minifi-cpp-0.3.0-bin.
> tar.gz)
> found in your build directory
>
> # Make sure the README, NOTICE, and LICENSE are present and correct
>
> # Run the resulting convenience binary and make sure it works as expected
>
> Be mindful of caveats for this initial release, listed in the README. Since
> the convenience binaries include
> the scripting extension [2], Python support is needed per our README [1]
>
> For some additional assistance, a package with configuration files for both
> a MiNiFI instance and a NiFi instance available at
> https://cwiki.apache.org/
> confluence/display/MINIFI/Releasing+MiNiFi#ReleasingMiNiFi-
> SampleNiFiandMiNiFiConfigurationtotransmitdatafromMiNiFitoNi
> FiviaSitetoSite
> The provided sample configuration bundle assumes that NiFi is configured to
> listen on port 8081 and has 10001 configured for Site to Site's
> nifi.remote.input.socket.port.
>
> # Send a response to the vote thread indicating a +1, 0, -1 based on your
> findings.
>
> Thank you for your time and effort to validate the release! Please let me
> know if you have any questions or need clarification.
>
> Thanks,
> Marc
>
> [1] https://github.com/apache/nifi-minifi-cpp/blob/
> MINIFICPP-304-RC0-0.3.0/
> README.md#system-requirements
> [2] https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=74685143
>

[ANNOUNCE] New NiFi PMC member Mike Moser

[Tony Kurc]

NiFi community,
On behalf of the Apache NiFi PMC, I am pleased to announce that Mike Moser
has accepted the PMC's invitation to join the Apache NiFi PMC.  We greatly
appreciate all of Mike's hard work and generous contributions to the
project. We look forward to continued involvement in the project.

Mike has been a long time code contributor to NiFi, he performed the final
release management duties for the 0.x line, has been involved with
verifying releases and always a delight on the mailing lists.

Please join us in congratulating and welcoming Mike to the Apache NiFi PMC.

Congratulations and welcome, Mike!

-- Tony

[ANNOUNCE] New Apache NiFi Committer Andy Christianson

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Andy
has accepted the PMC's invitation to become a committer on the Apache NiFi
project. We greatly appreciate all of Andy's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

In addition to contributing significant code to MiNiFi CPP, Andy has been
leading discussions and been the focal point for several major
improvements. His engagement with the community has been top notch, and
we're excited he accepted the PMC's invitation.

Andy, Welcome and congratulations!
Tony

[ANNOUNCE] New Apache NiFi Committer Mike Hogue

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Mike
Hogue has accepted the PMC's invitation to become a committer on the Apache
NiFi project. We greatly appreciate all of Mike's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

In the past several months, Mike has contributed on a number of fronts. He
was primary author on several new features in 1.4.0 to include the gRPC
bundle. He also improved SSL/TLS controller services, and made great
documentation improvements on LICENSE and NOTICE best practices and has
helped work down our pull request backlog by reviewing new contributions.

Welcome and congratulations!

Tony

[ANNOUNCE] New Apache NiFi Committer Peter Wicks

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Peter
Wicks has accepted the PMC's invitation to become a committer on the Apache
NiFi project. We greatly appreciate all of Peter's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

Peter has been contributing for over a year. Many of you have benefited
from useful improvements and new features centered mainly around databases
and record-based processors. I'm sure many of you have had the pleasure of
interacting with him on the mailing lists, as he's always been willing to
pitch in and make the Apache NiFi community stronger.

Welcome and congratulations!

Tony

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

[Tony Kurc]

+1 (binding)

Built on Ubuntu 14.04 with Java 1.8.0 and Maven 3.5.0. Verified hashes and
signature. Tested some simple flows. Tested some tls toolkit operations.
Did not see any issues with LICENSE or NOTICE files.

On Sat, Sep 30, 2017 at 4:17 AM, Koji Kawamura 
wrote:

> +1 (binding) Release this package as nifi-1.4.0
>
> Verified hashes, local build was successful on OS X, confirmed S2S
> communication with older versions.
>
>
>
> On Sat, Sep 30, 2017 at 9:27 AM, Andy LoPresto 
> wrote:
> > +1 (binding)
> >
> > Build environment: Mac OS X 10.11.6, Java 1.8.0_101, Maven 3.3.9, JCE
> > Unlimited Strength Cryptographic Jurisdiction Policies installed
> >
> > * verified GPG signature is valid and SHA512 digest
> > * verified all checksums
> > * verified all tests
> > * verified checkstyle
> > * verified Knox properties present in default nifi.properties
> > * verified normal flow
> > * verified ListenHTTP and HandleHTTPRequest only accept restricted SSLCS
> > * verified bad authorizers.xml (copied from 1.2.0 -- missing
> > managedAuthorizer) causes startup fail
> > * verified good authorizers.xml works
> > * verified secure instance works with client cert auth
> > * verified secure instance works with Knox SSO
> > * verified encrypted flow value migration works without Jasypt
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Sep 29, 2017, at 1:54 PM, Andrew Lim 
> wrote:
> >
> > +1 (non-binding)
> >
> > -Ran full clean install on OS X (10.11.4)
> > -Tested UI changes including Variable Registry UI
> > -Tested flows using Record reader/writer processors and controller
> services,
> > working as expected
> >
> >
> > On Sep 29, 2017, at 4:50 PM, Michael Moser  wrote:
> >
> > +1 (non-binding)
> >
> > Verified source package per release helper.
> > Built on Ubuntu 14.04, all unit tests and contrib-check pass.
> > Built on Windows 10, some unit tests fail and contrib-check fails on
> > "nifi-poi-processors: Too many files with unapproved license" but I
> > think this was expected.  The build without contrib-check and using
> > -DskipTests works.
> > Ran some simple flows that worked as expected.
> >
> > Many thanks to the community for all of the work put into this
> > release!  And thanks to Jeff for being RM.
> >
> >
> > On Fri, Sep 29, 2017 at 4:44 PM, Scott Aslan 
> wrote:
> >
> > +1 (non-binding) Release this package as nifi-1.4.0
> >
> > On Fri, Sep 29, 2017 at 11:52 AM, Mark Payne 
> wrote:
> >
> > +1 (binding)
> >
> > Verified hashes and checksum. Built with all unit tests and contrib-check
> > on OSX.
> >
> > Was able to startup and test simple flows worked as expected.
> >
> > On Sep 29, 2017, at 11:20 AM, Marc P.  wrote:
> >
> > +1 non-binding
> >
> > -- verified contrib-check
> > -- ran simple flows with MiNiFi
> > -- sigs and hashes look good.
> >
> > Thanks for sending this out Jeff!
> >
> >
> > On Fri, Sep 29, 2017 at 11:18 AM, Matt Gilman 
> > wrote:
> >
> > +1 (binding) Release this package as nifi-1.4.0
> >
> > On Fri, Sep 29, 2017 at 11:07 AM, Bryan Bende  wrote:
> >
> > +1 (binding)
> >
> > - Ran through the release helper and everything checked out.
> > - Ran a couple of sample flows with no issues
> >
> >
> > On Fri, Sep 29, 2017 at 9:46 AM, James Wing  wrote:
> >
> > Jeff, I agree the updated KEYS file has been published.  Thanks.
> >
> > On Fri, Sep 29, 2017 at 6:00 AM, Jeff  wrote:
> >
> > James,
> >
> > I had to do a hard reload of the page in Chrome, since the browser
> >
> > kept
> >
> > showing me a cached version without my key.  After the hard reload, I
> >
> > can
> >
> > see my key at https://dist.apache.org/repos/dist/dev/nifi/KEYS.
> >
> > Could
> >
> > you
> >
> > try opening the KEYS link in incognito mode and verify that my key is
> > there?
> >
> > Thanks,
> > Jeff
> >
> > On Fri, Sep 29, 2017 at 1:06 AM James Wing  wrote:
> >
> > +1 (binding). I ran through the release helper including signature,
> >
> > hashes,
> >
> > build, and testing the binary.  I checked the LICENSE and NOTICE
> >
> > files.
> >
> > Everything looks good to me.
> >
> > One thing I noted is that Jeff's GPG key is not yet in the public
> >
> > KEYS
> >
> > file
> >
> > at https://dist.apache.org/repos/dist/dev/nifi/KEYS, but it is
> >
> > added
> >
> > in
> >
> > the
> > master branch KEYS file to be published with the release.  I believe
> >
> > that
> >
> > is OK for the signature, we've done this before, and perhaps we
> >
> > should
> >
> > consider changing the helper text in the future.
> >
> > Thanks, Jeff, for putting this release together.
> >
> >
> > On Thu, Sep 28, 2017 at 12:54 PM, Jeff  wrote:
> >
> > 

Re: Separate MiNiFi projects in JIRA

[Tony Kurc]

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
> > > 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,
> > >  

Re: [DISCUSS] Apache Gitbox

[Tony Kurc]

Worth considering, this twitter post has been circulating the blogosphere:
https://twitter.com/agentdero/status/889582259522736128

I'd like to ensure we don't forget other means of providing patches
(attaching a patch to a ticket). While github is convenient to some, using
it as the sole source of providing contributions may be off-putting to some.

On Fri, Jul 28, 2017 at 6:36 PM, Tony Kurc <trk...@gmail.com> wrote:

> I'm a strong +0. I don't think think it is a huge step forward, but it
> isn't a step back either.
>
> On Jul 28, 2017 5:42 PM, "Andy LoPresto" <alopre...@apache.org> wrote:
>
>> +1 to enable gitbox.
>>
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On Jul 28, 2017, at 12:56 PM, Matt Burgess <mattyb...@gmail.com> wrote:
>>
>> +1, I meant to bring this up after I saw the conversation on the Apache
>> Streams list. Seems like a great improvement to the workflow!
>>
>>
>> On Jul 28, 2017, at 3:26 PM, Suneel Marthi <smar...@apache.org> wrote:
>>
>> +1 to move to gitbox
>>
>> On Fri, Jul 28, 2017 at 3:05 PM, Aldrin Piri <aldrinp...@gmail.com>
>> wrote:
>>
>> Excellent. Thanks for the input, Suneel. The before and after links are
>> especially helpful.
>>
>>
>> On Fri, Jul 28, 2017 at 3:00 PM, Suneel Marthi <smar...@apache.org>
>> 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 <aldrinp...@gmail.com>
>>
>> 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: [DISCUSS] Apache Gitbox

[Tony Kurc]

I'm a strong +0. I don't think think it is a huge step forward, but it
isn't a step back either.

On Jul 28, 2017 5:42 PM, "Andy LoPresto"  wrote:

> +1 to enable gitbox.
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 28, 2017, at 12:56 PM, Matt Burgess  wrote:
>
> +1, I meant to bring this up after I saw the conversation on the Apache
> Streams list. Seems like a great improvement to the workflow!
>
>
> On Jul 28, 2017, at 3:26 PM, Suneel Marthi  wrote:
>
> +1 to move to gitbox
>
> On Fri, Jul 28, 2017 at 3:05 PM, Aldrin Piri  wrote:
>
> Excellent. Thanks for the input, Suneel. The before and after links are
> especially helpful.
>
>
> 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: Binaries in embedded redis jar files

[Tony Kurc]

Mike -
Is there something about these binaries versus all of the other myriad
binaries (jars, .class files, dlls and .so files) included in the
convenience jar? I wouldn't think so, these are just more binary artifacts.
I honestly can't think of another apache project that provides similar
convenience binaries that have warnings such as those you mentioned.

Tony

On Wed, Jul 19, 2017 at 2:19 PM, Michael Moser  wrote:

> Whoa, this causes serious concerns for me.  While I can understand
> that the source code is the official ASF artifact, the nifi.apache.org
> site provides convenience binaries which I'm sure many people use.
> When NiFi 1.4.0 releases, we should write very conspicuous warnings on
> the Downloads page to advise users about this.
>
> -- Mike
>
>
> On Wed, Jul 19, 2017 at 2:04 PM, Joe Witt  wrote:
> > It is not a problem.  It would be an issue if those were part of our
> > source release which is the official apache release artifact.
> >
> >
> >
> > On Wed, Jul 19, 2017 at 1:58 PM, Joe Skora  wrote:
> >> I noticed a new jar dependency for Redis includes binaries.
> >>
> >> $ jar -xf
> >>> ~/.m2/repository/com/github/kstyrc/embedded-redis/0.6/
> embedded-redis-0.6.jar
> >>> $ ls -l
> >>> total 6292
> >>> drwxr-xr-x. 3 user1 users  36 Apr 12  2015 META-INF/
> >>> drwxr-xr-x. 3 user1 users  21 Apr 12  2015 redis/
> >>> -rw-r--r--. 1 user1 users 4236300 Apr 12  2015 redis-server-2.8.19
> >>> -rw-r--r--. 1 user1 users  806944 Apr 12  2015 redis-server-2.8.19.app
> >>> -rw-r--r--. 1 user1 users 1392640 Apr 12  2015 redis-server-2.8.19.exe
> >>> $ file redis-server*
> >>> redis-server-2.8.19: ELF 64-bit LSB executable, x86-64, version 1
> >>> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,
> >>> BuildID[sha1]=c59ab61e1d5b94e26d079b04e9e593b6be3f0230, not stripped
> >>> redis-server-2.8.19.app: Mach-O 64-bit executable
> >>> redis-server-2.8.19.exe: PE32+ executable (console) x86-64, for MS
> Windows
> >>>
> >>
> >> So, installing NiFi will include externally built binaries, not just
> >> scripts but full ELF, MacOS, and Windows PE binaries.
> >>
> >> Is this a problem for Apache?  Does this cause concern for anyone else?
> >>
> >> Regards,
> >> Joe
>

RTC clarification

[Tony Kurc]

All, I was having a discussion with Mike Hogue - a recent contributor - off
list, and he had some questions about the review process. And largely the
root of the question was, if a non-committer reviews a patch or PR (which
Mike has spent some time doing), is that considered a "review"? I didn't
have the answers, so I went on a hunt for documentation. I started with the
Contributor Guide [1]. The guide describes reviewing, and calls out a
Reviewer role, but doesn't specifically point out that Reviewer is a
committer, just that a committer "can actively promote contributions into
the repository", and goes on to imply the non-committers can review.

Given this, I was unable to answer this question:
If a committer "X" submits a patch or PR, it is reviewed by a non-committer
"Y", does that review satisfy the RTC requirement, and "X" may merge in the
patch?

I found a related discussion on the email list in March [2], which I think
implies at least some of the community assumed the canonical review must be
by a committer. I also went back a bit to early days [3], where Benson
implied a much less "formal" review process.

What I'm hoping for is hopefully come to a consensus of what our project
expectations are and document in the Contributor Guide. My expectation was
that non-committers could review, similar to what Sean discussed on this
thread for Apache Gossip (incubating) [4]. However, I don't believe this is
the current consensus.

Thoughts?

Tony

1.
https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-CodeReviewProcess
2.
https://mail-archives.apache.org/mod_mbox/nifi-dev/201703.mbox/%3CCALJK9a7onOKo%3DXtAEmL7PSBUEBEqOOhcT9WSz-RZaNxqV6q%3Dmg%40mail.gmail.com%3E
3.
https://mail-archives.apache.org/mod_mbox/nifi-dev/201501.mbox/%3CCALhtWkf67UpOe9W9HQ3RSn00xb_=c6zmxn+_sefwthpqru5...@mail.gmail.com%3E
4.
http://mail-archives.apache.org/mod_mbox/incubator-gossip-dev/201606.mbox/%3CCAN5cbe6P8aEEOLMA%2BPrfpQg9c_AWeSfvvmom8jAp%3Dk7wUpoVgQ%40mail.gmail.com%3E

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Tony Kurc]

I don't have any concerns, looks good!

On Thu, Jul 6, 2017 at 2:01 AM, Aldrin Piri  wrote:

> Looks good.  Thanks for compiling this, Joe.
>
> On Tue, Jul 4, 2017 at 9:50 AM, Joe Witt  wrote:
>
> > Team,
> >
> > It's that time again to submit our board report for Apache NiFi.
> > Please see below draft.  If you have any suggestions/fixes, edits
> > please advise.
> >
> > I'll submit the report in a few days.
> >
> > Thanks
> > Joe
> >
> > +_+_+_+_+_+_+_
> >
> > ## Description:
> >  - Apache NiFi is an easy to use, powerful, and reliable system to
> >process and distribute data.
> >  - Apache NiFi MiNiFi is an edge data collection agent built to
> seamlessly
> >integrate with and leverage the command and control of NiFi. There are
> >both Java and C++ implementations.
> >  - Apache NiFi Registry is a centralized registry for key configuration
> > items
> >including flow versions, assets, and extensions for Apache NiFi
> >and Apache MiNiFi.
> >  - Apache NiFi Nar Maven Plugin is a release artifact used for supporting
> >the NiFi classloader isolation model.
> >
> > ## Issues:
> >  - There are no issues requiring board attention at this time.
> >
> > ## Activity:
> >  - Based on board feedback in last report the descriptions above have
> been
> >simplified to avoid confusing child/subproject terminology.  We have
> >successfully conducted and completed name searches for the MiNiFi and
> >Registry efforts.
> >  - Conducted numerous releases as listed below.  The 0.7.x releases
> focused
> >on providing simple bug fixes and resolving reported CVEs.  The 1.x
> >releases brought about stability, performance improvements, and
> > addressed
> >reported CVEs.  Further, in the 1.x releases numerous substantive
> > features
> >were introduced including the ability to run multiple versions of the
> > same
> >components and support for both format and schema aware record
> > processors
> >to easily handle cases like acquisition, SQL based routing,
> enrichment,
> >conversion, and delivery of record oriented data.  These make many
> > common
> >record oriented use cases far more performant, intuitive, and retain
> the
> >full power of NiFi's provenance features.
> >
> > ## Health report:
> >  - Health of the community is strong and indicators of strength continue
> >trending in the right direction. Mailing list and JIRA activity is
> > strong.
> >ASF Hipchat is serving as an on-ramp for new users to our mailing list
> > and
> >JIRA systems. We continue to see new users and contributors. The PMC
> and
> >committer ranks grew again during this reporting cycle and the
> pipeline
> >is encouraging. We're generating many releases with new release
> managers
> >stepping up often. The team handles security reports swiftly and
> follows
> >ASF security team published processes effectively.
> >
> > ## PMC changes:
> >
> >  - Currently 22 PMC members.
> >  - New PMC members:
> > - Koji Kawamura was added to the PMC on Fri May 26 2017
> > - Pierre Villard was added to the PMC on Sun May 21 2017
> > - Yolanda Davis was added to the PMC on Wed May 17 2017
> >
> > ## Committer base changes:
> >
> >  - Currently 34 committers.
> >  - New commmitters:
> > - Marc Parisi was added as a committer on Thu Jun 01 2017
> > - Andrew M. Lim was added as a committer on Wed May 31 2017
> >
> > ## Releases:
> >
> >  - Apache NiFi 1.3.0 was released June 9 2017.
> >  - Apache NiFi 0.7.4 was released June 9 2017.
> >  - Apache NiFi MiNiFi (java) 0.2.0 was released May 19 2017.
> >  - Apache NiFi 0.7.3 was released May 19 2017.
> >  - Apache NiFi MiNiFi (cpp) 0.2.0 was released May 14 2017.
> >  - Apache NiFi 1.2.0 was released May 10 2017.
> >
> > ## Mailing list activity:
> >
> >  - Activity on the mailing lists remains extremely high with a mixture
> >of new users, contributors, and deeper more experienced users and
> >contributors sparking discussion and questions and filing bugs or
> >new features.
> >
> >  - us...@nifi.apache.org:
> > - 512 subscribers (up 39 in the last 3 months):
> > - 936 emails sent to list (846 in previous quarter)
> >
> >  - dev@nifi.apache.org:
> > - 367 subscribers (up 24 in the last 3 months):
> > - 1018 emails sent to list (925 in previous quarter)
> >
> >  - iss...@nifi.apache.org:
> > - 42 subscribers (up 4 in the last 3 months):
> > - 7936 emails sent to list (6592 in previous quarter)
> >
> >
> > ## JIRA activity:
> >
> >  - 573 JIRA tickets created in the last 3 months
> >  - 421 JIRA tickets closed/resolved in the last 3 months
> >
>

Re: NiFi Assembly NOTICE/LICENSE Maintenance

[Tony Kurc]

Joe et al.,
I was helping Mike out of band on this and think we got a bit confused,
mainly I think because of the current nifi-assembly NOTICE and seemingly
including things that I think you said shouldn't be (per your 2nd point).

Also, some of the phrasing you used was a little bit confusing and Mike and
I interpreted it differently. If a nar bundles something, and because the
assembly bundles the nar, I have been under the assumption that anything in
the nar NOTICE and LICENSE would need to be included in the assembly NOTICE
and LICENSE. I think you were saying this (and it is the case for this PR).

What was confusing is that Netty is in the current assembly NOTICE in two
areas [1][2]. The latter appears to include things that are modified
versions [3] as well as things that are optionally depended on [4]. I think
that based on what you're saying is that the "optionally depends on", like
[4] on should maybe be removed and new ones shouldn't be included as Mike
brings in the new "contains a modified version" portions that come along
with the new NOTICE.

Also, for what it is worth, Mike brought what I consider easy cases (google
protocol buffers being the same LICENSE text. the new Netty being a
superset of the old Netty), I was hoping what came out of the discussion is
what to do if two different versions of the same named dependency have
vastly different NOTICES. I'm pretty sure the right answer is to throw a
version on the dependency in the NOTICE (e.g. this line:

(ASLv2) Apache Commons Net

becomes:

(ASLv2) Apache Commons Net (x.y.z)

1. https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L939
2. https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1117
3. https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1163
4. https://github.com/apache/nifi/blame/master/nifi-assembly/NOTICE#L1179


On Wed, Jun 28, 2017 at 6:25 PM, Michael Hogue <michael.p.hogu...@gmail.com>
wrote:

> Joe,
>
>Thanks much for the detailed response. That's really helpful in
> determining what i should and shouldn't do w.r.t LICENSEs and NOTICEs. I'll
> capture this in the contributor guide as well.
>
> Thanks again,
> Mike
>
> On Wed, Jun 28, 2017 at 1:44 PM Mike Hogue <hogu...@gmail.com> wrote:
>
> > Not a problem, assuming i'm able to edit the contributor's guide.
> >
> > On Wed, Jun 28, 2017 at 1:43 PM Tony Kurc <trk...@gmail.com> wrote:
> >
> > > Mike,
> > > while it is fresh in your head, any chance you have cycles to
> synthesize
> > > this and put this up on the contributor's guide?
> > >
> > > Tony
> > >
> > > On Wed, Jun 28, 2017 at 11:33 AM, Joe Witt <joe.w...@gmail.com> wrote:
> > >
> > > > Michael,
> > > >
> > > > Thanks for being so diligent on the L considerations.
> > > >
> > > > For the binary dependencies you're listing here I'd take the
> following
> > > > approach:
> > > > 1) For google rpc dependency that is a new version but appears to be
> > > > the same LICENSE text I'd simply update this line [1] to say
> > > > The binary distribution of this product bundles 'Google Protocol
> > > > Buffers Java 2.5.0 and 3.3.1' -OR-
> > > > The binary distribution of this product bundles 'Google Protocol
> > Buffers
> > > > Java'
> > > >
> > > > Also, be sure your nar's LICENSE includes the proper entry google rpc
> > > > in its license.  See other nars for examples of this.  You might have
> > > > already done this but I've not looked at the totality of the PR.
> > > >
> > > > 2) For Netty I think we're already covered sufficiently with our
> > > > existing notice details as seen in our assembly NOTICE now [2].  But
> > > > you should be sure to have a similar entry in your nar's NOTICE.  The
> > > > other information they have in their NOTICE (of which 4.1 appears to
> > > > be a superset) could be carried forward but all the binary references
> > > > are irrelevant for what I'll describe in #3 next.  Their NOTICE
> > > > entries which say "this includes a modified portion of" should
> > > > probably be carried forward in the NOTICE in the nar and assembly
> > > > level.  Since the 4.1 NOTICE is a superset I'd just use that one only
> > > > [3]
> > > >
> > > > 3) Whether some binary dependencies NOTICE calls out a transitive
> > > > binary dependency it might or might not have is not relevant.  What
> is
> > > > relevant is which transitive dependencies, no matter how many levels
> > > > deep it comes i

Re: NiFi Assembly NOTICE/LICENSE Maintenance

[Tony Kurc]

Mike,
while it is fresh in your head, any chance you have cycles to synthesize
this and put this up on the contributor's guide?

Tony

On Wed, Jun 28, 2017 at 11:33 AM, Joe Witt <joe.w...@gmail.com> wrote:

> Michael,
>
> Thanks for being so diligent on the L considerations.
>
> For the binary dependencies you're listing here I'd take the following
> approach:
> 1) For google rpc dependency that is a new version but appears to be
> the same LICENSE text I'd simply update this line [1] to say
> The binary distribution of this product bundles 'Google Protocol
> Buffers Java 2.5.0 and 3.3.1' -OR-
> The binary distribution of this product bundles 'Google Protocol Buffers
> Java'
>
> Also, be sure your nar's LICENSE includes the proper entry google rpc
> in its license.  See other nars for examples of this.  You might have
> already done this but I've not looked at the totality of the PR.
>
> 2) For Netty I think we're already covered sufficiently with our
> existing notice details as seen in our assembly NOTICE now [2].  But
> you should be sure to have a similar entry in your nar's NOTICE.  The
> other information they have in their NOTICE (of which 4.1 appears to
> be a superset) could be carried forward but all the binary references
> are irrelevant for what I'll describe in #3 next.  Their NOTICE
> entries which say "this includes a modified portion of" should
> probably be carried forward in the NOTICE in the nar and assembly
> level.  Since the 4.1 NOTICE is a superset I'd just use that one only
> [3]
>
> 3) Whether some binary dependencies NOTICE calls out a transitive
> binary dependency it might or might not have is not relevant.  What is
> relevant is which transitive dependencies, no matter how many levels
> deep it comes in, we pull into our nars or convenience binaries.  They
> must all be accounted for properly if we're including them.  See here
> for the general guidance on this [4].
>
> I realize the L stuff can be a bit daunting, especially at first or
> in complex and highly dependency heavy contributions.  Indeed it can
> feel like no good deed goes unpunished.  But we can definitely help
> you work through it.
>
> Thanks!
> Joe
>
>
> [1] https://github.com/m-hogue/nifi/blob/4b845b39f36ae38470017ea61b104d
> 01310b8f16/nifi-assembly/LICENSE#L1086
> [2] https://github.com/apache/nifi/blob/master/nifi-assembly/NOTICE#L939
> [3] https://github.com/netty/netty/blob/4.1/NOTICE.txt
> [4] https://nifi.apache.org/licensing-guide.html
>
> On Tue, Jun 27, 2017 at 10:26 PM, Tony Kurc <trk...@gmail.com> wrote:
> > For reference:
> > Netty 4.1 NOTICE
> > https://github.com/netty/netty/blob/4.1/NOTICE.txt
> > Netty 3.7  NOTICE
> > https://github.com/netty/netty/blob/3.7/NOTICE.txt
> >
> >
> >
> >
> > On Tue, Jun 27, 2017 at 10:21 PM, Tony Kurc <trk...@gmail.com> wrote:
> >
> >> Background, I asked Mike how he put together the LICENSE, and why he
> added
> >> a separate section in the LICENSE for Google Protocol Buffers 3.3.1, and
> >> his answer that made sense was "well, what existed there was there had a
> >> version (2.5.0)".
> >>
> >> Interesting note, the Google Protocol Buffers LICENSE looks to be the
> >> same.
> >>
> >> Sort of the opposite issue with Netty. NOTICE didn't have a version of
> >> Netty, and the NOTICES between versions were fairly different.
> >>
> >>
> >>
> >> On Tue, Jun 27, 2017 at 10:16 PM, Michael Hogue <
> >> michael.p.hogu...@gmail.com> wrote:
> >>
> >>> Hello all,
> >>>
> >>>I'm attempting to merge a LICENSE and NOTICE i've created for a new
> >>> grpc
> >>> processor bundle [1,2] into the NiFi assembly. I've run into a couple
> of
> >>> things i don't know how to resolve:
> >>>
> >>> 1. If I add a new (transitive) dependency with a newer version than
> exists
> >>> elsewhere in the code _and_ the licenses are the same except for the
> >>> version, do the license for each of the versions need spelled out in
> the
> >>> nifi assembly LICENSE file?
> >>>
> >>> 2. One of the grpc dependencies i've added pulls in a version of netty
> >>> fairly different than what exists in the code already. Should there be
> a
> >>> separate block in the assembly NOTICE if they differ? Is it sufficient
> to
> >>> add to the existing netty block?
> >>>
> >>> PR reference:
> >>> https://github.com/apache/nifi/pull/1947/files#diff-c3a3e6d0
> >>> 27b17e530efdb23269e95968R1132
> >>>
> >>> Thanks,
> >>> Mike
> >>>
> >>> [1] https://issues.apache.org/jira/browse/NIFI-4037
> >>> [2] https://issues.apache.org/jira/browse/NIFI-4038
> >>>
> >>
> >>
>

Re: NiFi Assembly NOTICE/LICENSE Maintenance

[Tony Kurc]

For reference:
Netty 4.1 NOTICE
https://github.com/netty/netty/blob/4.1/NOTICE.txt
Netty 3.7  NOTICE
https://github.com/netty/netty/blob/3.7/NOTICE.txt




On Tue, Jun 27, 2017 at 10:21 PM, Tony Kurc <trk...@gmail.com> wrote:

> Background, I asked Mike how he put together the LICENSE, and why he added
> a separate section in the LICENSE for Google Protocol Buffers 3.3.1, and
> his answer that made sense was "well, what existed there was there had a
> version (2.5.0)".
>
> Interesting note, the Google Protocol Buffers LICENSE looks to be the
> same.
>
> Sort of the opposite issue with Netty. NOTICE didn't have a version of
> Netty, and the NOTICES between versions were fairly different.
>
>
>
> On Tue, Jun 27, 2017 at 10:16 PM, Michael Hogue <
> michael.p.hogu...@gmail.com> wrote:
>
>> Hello all,
>>
>>I'm attempting to merge a LICENSE and NOTICE i've created for a new
>> grpc
>> processor bundle [1,2] into the NiFi assembly. I've run into a couple of
>> things i don't know how to resolve:
>>
>> 1. If I add a new (transitive) dependency with a newer version than exists
>> elsewhere in the code _and_ the licenses are the same except for the
>> version, do the license for each of the versions need spelled out in the
>> nifi assembly LICENSE file?
>>
>> 2. One of the grpc dependencies i've added pulls in a version of netty
>> fairly different than what exists in the code already. Should there be a
>> separate block in the assembly NOTICE if they differ? Is it sufficient to
>> add to the existing netty block?
>>
>> PR reference:
>> https://github.com/apache/nifi/pull/1947/files#diff-c3a3e6d0
>> 27b17e530efdb23269e95968R1132
>>
>> Thanks,
>> Mike
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-4037
>> [2] https://issues.apache.org/jira/browse/NIFI-4038
>>
>
>

Re: NiFi Assembly NOTICE/LICENSE Maintenance

[Tony Kurc]

Background, I asked Mike how he put together the LICENSE, and why he added
a separate section in the LICENSE for Google Protocol Buffers 3.3.1, and
his answer that made sense was "well, what existed there was there had a
version (2.5.0)".

Interesting note, the Google Protocol Buffers LICENSE looks to be the same.

Sort of the opposite issue with Netty. NOTICE didn't have a version of
Netty, and the NOTICES between versions were fairly different.



On Tue, Jun 27, 2017 at 10:16 PM, Michael Hogue  wrote:

> Hello all,
>
>I'm attempting to merge a LICENSE and NOTICE i've created for a new grpc
> processor bundle [1,2] into the NiFi assembly. I've run into a couple of
> things i don't know how to resolve:
>
> 1. If I add a new (transitive) dependency with a newer version than exists
> elsewhere in the code _and_ the licenses are the same except for the
> version, do the license for each of the versions need spelled out in the
> nifi assembly LICENSE file?
>
> 2. One of the grpc dependencies i've added pulls in a version of netty
> fairly different than what exists in the code already. Should there be a
> separate block in the assembly NOTICE if they differ? Is it sufficient to
> add to the existing netty block?
>
> PR reference:
> https://github.com/apache/nifi/pull/1947/files#diff-
> c3a3e6d027b17e530efdb23269e95968R1132
>
> Thanks,
> Mike
>
> [1] https://issues.apache.org/jira/browse/NIFI-4037
> [2] https://issues.apache.org/jira/browse/NIFI-4038
>

Re: NIFI-3641

[Tony Kurc]

Mike,
Do you plan to put in a new ticket for a gRPC processor without the
site-to-site?

On Wed, Jun 7, 2017 at 10:40 AM, Joe Witt <joe.w...@gmail.com> wrote:

> i'm definitely a +1.  That path makes total sense to me and lets us
> all learn a bit more about gRPC and what it could do as we move along.
>
> Thanks
>
> On Wed, Jun 7, 2017 at 10:35 AM, Michael Hogue
> <michael.p.hogu...@gmail.com> wrote:
> > Koji,
> >
> >I like that idea and it seems like a simple enough approach for
> > introducing gRPC into nifi. I appreciate all of the feedback. If there
> are
> > no objections, i'll move forward with Koji's suggestion.
> >
> > Thanks,
> > Mike
> >
> > On Tue, Jun 6, 2017 at 10:58 PM Koji Kawamura <ijokaruma...@gmail.com>
> > wrote:
> >
> >> Hi Mike,
> >>
> >> I like the idea of adding gRPC as an option for NiFi to communicate
> >> with other NiFi (s2s) or other server endpoint which can talk via
> >> gRPC.
> >>
> >> I had implemented HTTP for s2s before. It was not an easy task (at
> >> least for me) to make the new protocol align with existing
> >> terminology, behavior and the same level of support.
> >> We need to implement both s2s client and server side and that would
> >> require a huge effort.
> >>
> >> I personally prefer starting with option 2 (enabling flow file sharing
> >> to arbitrary external
> >> services via gRPC). Probably start with a simple gRPC client processor
> >> similar to InvokeHTTP.
> >> Then we would expand our support by adding server side processor
> >> similar to HandleHTTPRequest/Response.
> >> After that, we could add support for gRPC way load-balancing, to
> >> distribute requests among NiFi nodes in a cluster those are running
> >> HandleGRPCRequest/Response.
> >> At this point, we need a Load balancer described in this design
> document:
> >> https://github.com/grpc/grpc/blob/master/doc/load-balancing.md
> >>
> >> If we go through this route, we will have more detailed knowledge on
> >> how gRPC works and more clear idea on how we can apply it to NiFi s2s
> >> mechanism.
> >>
> >> I maybe wrong since I just started reading about gRPC technology..
> >>
> >> Thanks,
> >> Koji
> >>
> >> On Wed, Jun 7, 2017 at 11:29 AM, Michael Hogue
> >> <michael.p.hogu...@gmail.com> wrote:
> >> > Indeed, Tony. Thanks for clearing that up.
> >> >
> >> > The first option (gRPC for s2s) may offer an opportunity to leverage a
> >> > library for some of the things you'd likely care about with
> distributed
> >> > comms, such as load balancing, rather than implementing that
> ourselves.
> >> > gRPC has pluggable load balancing, authentication, and transport
> >> protocols,
> >> > so you're still free to provide your own implementation.
> >> >
> >> > I think the latter option (enabling flow file sharing to arbitrary
> >> external
> >> > services via gRPC) may open a number of additional doors not
> previously
> >> > available with tensorflow as the motivator.
> >> >
> >> > I'm happy to choose one of these things, but i thought it'd be wise to
> >> open
> >> > the conversation to the dev list prior to starting.
> >> >
> >> > Thanks,
> >> > Mike
> >> >
> >> > On Tue, Jun 6, 2017 at 8:22 PM Tony Kurc <trk...@gmail.com> wrote:
> >> >
> >> >> Joe, the ticket [1] mentions tensorflow, implying, to some extent,
> that
> >> >> option A from my email wouldn't cut the mustard.
> >> >>
> >> >> 1. https://issues.apache.org/jira/browse/NIFI-3641
> >> >>
> >> >> On Jun 6, 2017 8:15 PM, "Joe Witt" <joe.w...@gmail.com> wrote:
> >> >>
> >> >> > Mike, Tony,
> >> >> >
> >> >> > This certainly sounds interesting and from reading through the
> >> >> > motivations/design behind it there are clearly some well thought
> out
> >> >> > reasons for it.
> >> >> >
> >> >> > For site-to-site support I can see advantages for interoperability.
> >> >> > For other factors it would be good to identify limitations of the
> >> >> > current options (raw sockets/http) so that we can clearly and
> >> >> &

Re: NIFI-3641

[Tony Kurc]

Joe, the ticket [1] mentions tensorflow, implying, to some extent, that
option A from my email wouldn't cut the mustard.

1. https://issues.apache.org/jira/browse/NIFI-3641

On Jun 6, 2017 8:15 PM, "Joe Witt" <joe.w...@gmail.com> wrote:

> Mike, Tony,
>
> This certainly sounds interesting and from reading through the
> motivations/design behind it there are clearly some well thought out
> reasons for it.
>
> For site-to-site support I can see advantages for interoperability.
> For other factors it would be good to identify limitations of the
> current options (raw sockets/http) so that we can clearly and
> measurable improve gaps for certain use cases.  Would be good to hear
> any of those you have in mind.
>
> Outside of site-to-site it seems like it could make sense for a
> processor configured with a given gRPC/proto being able to talk to
> another service to share data.  Is that planned as part of this effort
> or is that just what the referenced JIRA was about?
>
> In either case this seems like one heck of an initial area to
> contribute to and a good discussion point!  Thanks
>
> Joe
>
> http://www.grpc.io/blog/principles
>
> On Tue, Jun 6, 2017 at 7:21 PM, Tony Kurc <trk...@gmail.com> wrote:
> > Mike,
> > I think what you're saying is you are debating two options:
> >
> > A) gRPC as a transport mechanism and support the deployment use cases
> from
> > the HTTP s2s document [1] to include using nifi-specific peer selection
> in
> > the client if the destination is a cluster.
> > B) Building a different implementation with an additional deployment
> case,
> > which is sending from a client (in the diagrams as NiFi site-to-site
> > client) to a cluster which isn't NiFi and delegating peer selection "to
> > gRPC" which lightens what the receiving cluster would have to implement?
> >
> > Sound pretty close to the decision you're looking for input on?
> >
> > 1.
> > https://cwiki.apache.org/confluence/display/NIFI/
> Support+HTTP%28S%29+as+a+transport+mechanism+for+Site-
> to-Site#SupportHTTP(S)asatransportmechanismforSite-
> to-Site-Deploymentexamples
> >
> > On Tue, Jun 6, 2017 at 2:28 PM, Michael Hogue <
> michael.p.hogu...@gmail.com>
> > wrote:
> >
> >> All,
> >>
> >>As an initial dive into nifi i elected to take a stab at NIFI-3641
> >> <https://issues.apache.org/jira/browse/NIFI-3641> (in particular, the
> >> site-to-site bit), but i've got a few high level questions before taking
> >> off down a path.
> >>
> >>Would it be more desirable to have a gRPC site-to-site mechanism or
> the
> >> ability to generally interact with external gRPC services, such as
> tensor
> >> flow, in a processor? That might help guide the approach I take in
> >> addressing the issue. I'm not entirely sure it's possible to do both
> with
> >> the same solution since the current site-to-site API assumes the other
> end
> >> is a nifi. On top of that, gRPC provides a number of load balancing,
> remote
> >> gRPC server (i.e. peer) selection, and serialization mechanisms that the
> >> current site-to-site implementation does itself.
> >>
> >>What i'm looking for here are some thoughts and/or guidance on a
> >> recommended approach and intended goal.
> >>
> >> Thanks,
> >> Mike
> >>
>

Re: NIFI-3641

[Tony Kurc]

Mike,
I think what you're saying is you are debating two options:

A) gRPC as a transport mechanism and support the deployment use cases from
the HTTP s2s document [1] to include using nifi-specific peer selection in
the client if the destination is a cluster.
B) Building a different implementation with an additional deployment case,
which is sending from a client (in the diagrams as NiFi site-to-site
client) to a cluster which isn't NiFi and delegating peer selection "to
gRPC" which lightens what the receiving cluster would have to implement?

Sound pretty close to the decision you're looking for input on?

1.
https://cwiki.apache.org/confluence/display/NIFI/Support+HTTP%28S%29+as+a+transport+mechanism+for+Site-to-Site#SupportHTTP(S)asatransportmechanismforSite-to-Site-Deploymentexamples

On Tue, Jun 6, 2017 at 2:28 PM, Michael Hogue 
wrote:

> All,
>
>As an initial dive into nifi i elected to take a stab at NIFI-3641
>  (in particular, the
> site-to-site bit), but i've got a few high level questions before taking
> off down a path.
>
>Would it be more desirable to have a gRPC site-to-site mechanism or the
> ability to generally interact with external gRPC services, such as tensor
> flow, in a processor? That might help guide the approach I take in
> addressing the issue. I'm not entirely sure it's possible to do both with
> the same solution since the current site-to-site API assumes the other end
> is a nifi. On top of that, gRPC provides a number of load balancing, remote
> gRPC server (i.e. peer) selection, and serialization mechanisms that the
> current site-to-site implementation does itself.
>
>What i'm looking for here are some thoughts and/or guidance on a
> recommended approach and intended goal.
>
> Thanks,
> Mike
>

[ANNOUNCE] New Apache NiFi Committer Marc Parisi

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Marc
Parisi has accepted the PMC's invitation to become a committer on the
Apache NiFi project. We greatly appreciate all of Marc's hard work and
generous contributions to the project. We look forward to his continued
involvement in the project.

Marc has been contributing heavily to MiNiFi C++ for the past several
months, really bringing energy to that piece of the project. He's been
making heavy code contributions, and as many of you have discovered, active
and helpful on the mailing lists and is a willing reviewer. Marc also
brings with him experience with another Apache project, Accumulo, where he
is a committer and PMC member.

Welcome and congratulations!

Tony

[ANNOUNCE] New Apache NiFi Committer Drew Lim

[Tony Kurc]

On behalf of the Apache NiFI PMC, I am very pleased to announce that Drew
Lim has accepted the PMC's invitation to become a committer on the Apache
NiFi project. We greatly appreciate all of Drew's hard work and generous
contributions to the project. We look forward to his continued involvement
in the project.

In my opinion, one of the strengths of NiFi is that someone can launch the
UI, do some light (often built-in) reading, and get started "making data
flow" in a short amount of time. Drew has been instrumental in making this
happen, over the past year contributing to the wiki and making the built-in
documentation correct and approachable. We all know the Apache adage
"Community > Code", and Drew's contributions are key to ensuring the health
of the community.

Welcome and congratulations!

--Tony

[ANNOUNCE] New Apache NiFi PMC Member - Koji Kawamura

[Tony Kurc]

On behalf of the Apache NiFi PMC, I am pleased to announce that Koji
Kawamura has accepted the PMC's invitation to join the Apache NiFi PMC.  We
greatly appreciate all of Koji's hard work and generous contributions to
the project. We look forward to continued involvement in the project.

Koji has been contributing code NiFi since 2015, taking point on important
parts of the project like improving site-to-site. Beyond code, Koji is
active in building the community through blogging on technical topics,
generating interest on social media (@apachenifi #NiFi) like twitter, and
giving talks at conferences. Koji has been keeping the project strong by
being active in reviewing new contributions and verifying releases.

Please join us in congratulating and welcoming Koji to the Apache NiFi PMC.

Congratulations and welcome, Koji!

-- Tony

[ANNOUNCE] New Apache NiFi PMC Member - Pierre Villard

[Tony Kurc]

On behalf of the Apache NiFi PMC, I am pleased to announce that Pierre
Villard has accepted the PMC's invitation to join the Apache NiFi PMC.  We
greatly appreciate all of Pierre's hard work and generous contributions to
the project. We look forward to continued involvement in the project.

Pierre has been a long time code contributor to both NiFi and MiNiFi. In
addition to that, he's spurred the community through his blogging -
teaching people how to use, operate, and monitor NiFi. He's a prolific
reviewer of contributions, and active in the important task of verifying
releases.

Please join us in congratulating and welcoming Pierre to the Apache NiFi
PMC.

Congratulations and welcome, Pierre!

-- Tony

[ANNOUNCE] New Apache NiFi PMC Member - Yolanda Davis

[Tony Kurc]

On behalf of the Apache NiFi PMC, I am pleased to announce that Yolanda
Davis has accepted the PMC's invitation to join the Apache NiFi PMC.  We
greatly appreciate all of Yolanda's hard work and generous contributions to
the project. We look forward to continued involvement in the project.

I know many people have interacted with Yolanda maybe at one of her
conference talks, or had the pleasure of working with her on reviews, or
used some of the features she's contributed and put a lot of work into
making them well tested and easy to use. If so, I think you'd agree it is
hard to interact with Yolanda and not get excited about not only NiFi but
the entire Apache way. If not, you're in for a treat when you get the
chance!

Please join us in congratulating and welcoming Yolanda to the Apache NiFi
PMC.

Congratulations and welcome, Yolanda!

-- Tony

Re: [VOTE] Release Apache NiFi MiNiFi 0.2.0

[Tony Kurc]

+1 (binding)

- verified signatures
- verified hashes
- build cleanly
- verified a simple flow
- I think c2 worked as expected
- ran toolkit's config.sh and did some converting without issue


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:  c182d71ba298a41a336da139f435f10a253997d677fc4ae8820b261ea8c3a4c2
> 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=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 0.7.3

[Tony Kurc]

+1 (binding)

- checked hashes
- verified signature
- built cleanly (java 1.8.0_102, Amazon Linux 2017.03)
- checked over license, notice and readme
- launched and ran some simple flows



On Sun, May 14, 2017 at 8:33 PM, Michael Moser  wrote:

> Hello Apache NiFi community,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi nifi-0.7.3.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1105
>
> The Git tag is nifi-0.7.3-RC1
> The Git commit ID is 78532ef44fb8b830a5316ce10a5cc7862bc3b5b2
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 78532ef44fb8b830a5316ce10a5cc7862bc3b5b2
>
> Checksums of nifi-0.7.3-source-release.zip:
> MD5: bcd2b37ca38a15ed181879e0b6fa9ba9
> SHA1: 68cae664b54d49c046a2c8e41bdafca404084acf
> SHA256: 7d6d9bae4ccae9a4d249fc7830b5abed1ecdd4f2699f846f1829f306cda0
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/mosermw.asc
>
> KEYS file available here (NOTE: the key for mosermw is not yet in the
> KEYS file):
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 29 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316020=12340527
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version0.7.3
>
> 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-${NIFI_VERSION}
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
>