Re: [discuss] NiFi support for Hadoop ecosystem components

[Jeremy Dyer]

I think option 2 is the best way to handle this.

Technology naturally changes over time and some components of Nifi might not 
make the most sense to keep around in the main line for the masses anymore. 
However I really like still having them there for people to very simply add if 
they so desire too. I see other platforms do this by adding a “contrib” repo. 
What if we had something like a “nifi-contrib” or “nifi-emeritus” repo in 
GitHub, Apache GitHub repo, where the community can still be involved as 
desired but also keep things readily available to those who might not even be 
heavily involved in the community?

I even see this as a sustainable pattern for any components that need “moved 
out”.

I wouldn’t even think those components in the “contrib” repo would require 
voting on for releases but someone, or a vendor, could update them via PRs 
after the official release.

Jeremy Dyer

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Chakravarty, G 
Sent: Friday, March 24, 2023 4:36:43 PM
To: dev@nifi.apache.org 
Subject: Re: [discuss] NiFi support for Hadoop ecosystem components

I am wondering if the standard Nifi jdbc/odbc processors with some basic 
testing with the common drivers like Simba etc. Hive drivers can help to 
alleviate the issue without having separate HiveQL processors.

GC

From: Bryan Bende 
Sent: Friday, March 24, 2023 4:05 PM
To: dev@nifi.apache.org 
Subject: Re: [discuss] NiFi support for Hadoop ecosystem components

I lean towards option 2 with the caveat that maybe we don't have to
retain every Hadoop related component when creating this separate set
of components. Mainly I'm thinking that Hive has been the most
problematic to maintain so maybe that is dropped all together. I think
it would be unfortunate to not have publicly available HDFS
processors.

On Fri, Mar 24, 2023 at 3:23 PM Matt Burgess  wrote:
>
> As one of the small number of people that fight the battle, I like the
> idea of Option 1 (full disclosure: I work for a vendor). From a
> community standpoint (I'm on the PMC) I'm not strongly opposed to
> Option 2 although I wouldn't want to be the one managing and releasing
> the artifacts :) Having said that, unless it remained maintained and
> released, I feel like it would just be a component graveyard (or maybe
> more like the Apache Attic), in which case it seems unnecessary and
> that's why I'm behind Option 1. Interested to hear others' thoughts of
> course.
>
> Thanks,
> Matt
>
> On Fri, Mar 24, 2023 at 2:07 PM Joe Witt  wrote:
> >
> > Team,
> >
> > For the full time NiFi has been in Apache we've built with support for
> > various Hadoop ecosystem components like HDFS, Hive, HBase, others,
> > and more recently formats/serialization modes like necessary for
> > Parquet, Orc, Iceberg, etc..
> >
> > All of these things however present endless challenges with
> > compatibility across different versions (Hive being the most difficult
> > by far), vendors (hadoop vendors, cloud vendors, etc..).  And also
> > super notably the incredible number of dependencies, dependency
> > conflicts, inclusions/exclusions, old log libs, vulnerability updates,
> > etc..  And last but certainly not least a big reason why our build has
> > grown so much.
> >
> > We have a couple options:
> > 1. Deprecate these components in NiFi 1.x and drop them entirely in
> > NiFi 2.x.  Leave this as a problem for vendors to deal with.  NiFi
> > users interacting with such components are nearly exclusively doing so
> > with vendors anyway.
> >
> > 2. Remove the components from NiFi main code line and create a
> > separate repo for 'nifi-hadoop-extensions'.  We manage those
> > independently and release them periodically.  They would be available
> > for people to grab the nars if they want to use them.  We include none
> > of them in the convenience binary going forward by default.
> >
> > 3. Change nothing.  Continue to battle with the above listed items.
> > This is admittedly a bit of a non-option.  We can't keep spending the
> > same time/energy on these we have.  It is a very small number of
> > people that fight this battle.
> >
> > Look forward to hearing thoughts on these options or others we might 
> > consider.
> >
> > Thanks

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0 - RC2

[Jeremy Dyer]

+1 (binding)

Verified hashes and confirmed positive build using same environment as RC1
which was causing issues.

Thanks Kevin

- Jeremy Dyer

On Tue, Mar 14, 2023 at 7:04 PM Matt Burgess  wrote:

> +1 (binding)
>
> Ran through release helper, built NiFi bundles/NARs using this version
> of the plugin, all looks good. Thanks for RM'ing Kevin!
>
> On Tue, Mar 14, 2023 at 5:00 PM Kevin Doran  wrote:
> >
> > Hello Apache NiFi Community,
> >
> > Issues with RC1 have been addressed in RC2, and I am pleased to again
> > be calling this vote for the source release of Apache NiFi NAR Maven
> > Plugin 1.5.0.
> >
> > The source being voted upon, including signatures, digests, etc. can
> > be found at:
> >
> https://repository.apache.org/content/repositories/orgapachenifi-1222/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
> >
> > The Git tag is nifi-nar-maven-plugin-1.5.0-RC2
> > The Git commit ID is 277f9e8998ca76a972c90d8ecf3f771414c86700
> >
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=277f9e8998ca76a972c90d8ecf3f771414c86700
> >
> > Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
> >
> > SHA512:
> a265587f8bfb31359cae2335394d88d76d36ae9806030e38fc9846264f20a4e70d642c4f0c08425b843794aaabaeea416b1104ede26671ffcbe001e1976d4efd
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/kdoran.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 4 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/projects/NIFI/versions/12352895
> >
> > Release note highlights can be found here:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12352895
> >
> > *The vote will be open for 24 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-nar-maven-plugin-1.5.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because ...
>

Re: [VOTE] Release Apache NiFi NAR Maven Plugin 1.5.0

[Jeremy Dyer]

-1 seeing same contrib check failures as Joe on Ubuntu 22 X86 machine

(base) ➜  nifi-nar-maven-plugin-1.5.0 mvn --version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 17.0.6, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.19.0-35-generic", arch: "amd64", family:
"unix"

I too could very well be doing something wrong.

- Jeremy Dyer


On Mon, Mar 13, 2023 at 5:30 PM Joe Witt  wrote:

> -1 (subject to change if I've done something goofy)
>
> I find contrib check failures.
>
> [INFO] --- checkstyle:3.2.0:check (check-style) @ nifi-nar-maven-plugin ---
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[29,8] (imports)
> UnusedImports: Unused import -
> org.apache.maven.artifact.repository.RepositoryRequest.
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[30,8] (imports)
> UnusedImports: Unused import -
> org.apache.maven.artifact.resolver.ArtifactNotFoundException.
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[31,8] (imports)
> UnusedImports: Unused import -
> org.apache.maven.artifact.resolver.ArtifactResolutionException.
> [WARNING] src/main/java/org/apache/nifi/NarMojo.java:[984,17] (blocks)
> LeftCurly: '{' at column 17 should be on the previous line.
> [WARNING]
> src/test/java/org/apache/nifi/extension/definition/extraction/ExtensionClassLoaderFactoryTest.java:[127]
> (regexp) RegexpSinglelineJava: Line has trailing whitespace.
>
> After actually removing/changing the mentioned lines it works as expected.
>
> Thanks
> Joe
>
> On Mon, Mar 13, 2023 at 12:57 PM Kevin Doran  wrote:
> >
> >  Edit: I meant to say that due to the narrow scope of this release and
> the
> > fact that it is currently blocking release of Apache NiFi 1.21.0, this
> vote
> > will be open for 24 hours as opposed to the normal 72 hours.
> >
> > On Mar 13, 2023 at 15:56:22, Kevin Doran  wrote:
> >
> > > Hello Apache NiFi Community,
> > >
> > > I am pleased to be calling this vote for the source release of Apache
> NiFi NAR Maven Plugin 1.5.0.
> > >
> > > The source being voted upon, including signatures, digests, etc. can
> be found at:
> > >
> https://repository.apache.org/content/repositories/orgapachenifi-1221/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/
> > >
> > > The Git tag is nifi-nar-maven-plugin-1.5.0-RC1
> > > The Git commit ID is ec2635b0474994861d3225538168e46638c0d2bb
> > >
> https://gitbox.apache.org/repos/asf?p=nifi-maven.git;a=commit;h=09d7bb9ff679d0eed9feaa066d2cbdd347a20204
> > >
> > > Checksum of nifi-nar-maven-plugin-1.5.0-source-release.zip:
> > >
> > > SHA512:
> f4b5ab2286319bd53ce5d872008667f63804ca77640e89e15759ffa26743b6854d642a8dec7784fbfc32fcccdfeb7b6b9a3c4daa00886d5d13161b1c2ed47c7f
> > >
> > > Release artifacts are signed with the following key:
> > > https://people.apache.org/keys/committer/kdoran.asc
> > >
> > > KEYS file available here:
> > > https://dist.apache.org/repos/dist/release/nifi/KEYS
> > >
> > > 3 issues were closed/resolved for this release:
> > > https://issues.apache.org/jira/projects/NIFI/versions/12352895
> > >
> > > Release note highlights can be found here:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12352895
> > >
> > > 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-nar-maven-plugin-1.5.0
> > > [ ] +0 no opinion
> > > [ ] -1 Do not release this package because ...
> > >
> > >
>

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

[Jeremy Dyer]

+1 (binding)

Signatures and hashes look good, build and tests work fine on ubuntu 22
system. Setup and ran some basic flows all of which worked as expected.
Looks good to me.

Thanks for getting the release together Joe

- Jeremy Dyer

On Wed, Feb 8, 2023 at 7:18 PM Kevin Doran  wrote:

>  +1 (binding)
>
> Ran through the normal verification steps / checked signatures and hashes.
> All looks good.
>
> Thanks for RM’ing, Joe!
>
> Kevin
>
> On Feb 8, 2023 at 14:33:31, Nissim Shiman 
> wrote:
>
> > +1 (non-binding)
> >
> > verified source release sha256/512 checksums
> >
> >
> > built and ran successfully using:Apache Maven 3.6.3 Java openjdk version:
> > 1.8.0_352
> > linux kernel 3.10.0-1160
> >
> >
> > Verified various simple flows.
> >
> > Noticed issue where content viewer doesn't handle very large files (i.e.
> > 100MB) well.  nifi screen looses look and feel when this occurs and
> > displays OutOfMemoryError
> >
> > Put in a jira for this  https://issues.apache.org/jira/browse/NIFI-11153
> >
> > This would be a very limited user initiated edge case, so I don't think
> > this is a blocker.
> >
> >
> > Thank you for the upcoming release!
> >
> > Nissim Shiman
> >
> >
> >On Monday, February 6, 2023 at 08:56:10 PM UTC, Joe Witt <
> > joew...@apache.org> wrote:
> >
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> NiFi
> > 1.20.0.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1220
> >
> > The source being voted upon and the convenience binaries can be found at:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.20.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.20.0-RC1
> > The Git commit ID is 81296b5b69a69d26afb8f8dec3a58a8363653890
> >
> >
> https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=81296b5b69a69d26afb8f8dec3a58a8363653890
> >
> > Checksums of nifi-1.20.0-source-release.zip:
> > SHA256: 694e9eec951caf628576a2aaa16e7ddadc11b9bf455f16d503bdd88aefdbfe66
> > SHA512:
> >
> >
> f54891aadbf58eaf4df465e99eb935ddbb47c70c1e329968098762f670eeed56a427ed88f21f150c056f8b057f7120127f3470afe4f4f89b80d659d7b8080339
> >
> > 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
> >
> > 205 issues were closed/resolved for this release:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12352581
> >
> > Release note highlights can be found here:
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.20.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.20.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> >
>

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

[Jeremy Dyer]

+1 (binding)

verified source, build from source on U22.04, verified functioning docker
builds, and confirmed valid SHAs

On Thu, Dec 1, 2022 at 10:16 AM Gábor Gyimesi  wrote:

> +1 (non-binding)
>
> - verified signature and hashes of source tar.gz file
> - verified git commit hash
> - built RC core and all extensions (excluding Tensorflow) with GCC 11.3 on
> Ubuntu 22.04
> - ran all unit, integration and docker system tests
> - verified contents of README.md, NOTICE, and LICENSE files
> - verified
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.13.0/nifi-minifi-cpp-0.13.0-bin-linux.tar.gz
> binary with simple flows having TailFile, GetFile, LogAttribute processors
> and communication through InvokeHTTP processor with NiFi's ListenHTTP
> processor
> - verified Prometheus metrics reporting with built binary and Prometheus
> 2.35.0
>
> Thanks,
> Gabor
>
> On Wed, 30 Nov 2022 at 11:58, Ferenc Gerlits  wrote:
>
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> NiFi
> > MiNiFi C++ 0.13.0.
> >
> > The source tarball, the binary build, plus signatures and digests can be
> > found at:
> > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.13.0/
> >
> > The Git tag is minifi-cpp-0.13.0-RC1
> > The Git commit ID is 4389b9ac05e43e1dbf908e9014787d07c8a9cd05
> >
> >
> https://github.com/apache/nifi-minifi-cpp/commit/4389b9ac05e43e1dbf908e9014787d07c8a9cd05
> >
> > Checksums of nifi-minifi-cpp-0.13.0-source.tar.gz:
> > SHA256: 9cbc37cb841dbd2b53412ded7ba59cd571181b659f647b9d35c3f3ac985337c1
> > SHA512:
> >
> >
> 3a69ef1894e4fdc2b2e4d7cd77f46debd86c52a70cfd1a7a76445ae976cfe12bd176cfad3a6aacda2a01aa2ff5810faf2e3d3a8e8ff0de5e460ae19f63db
> >
> > 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
> >
> > 85 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/projects/MINIFICPP/versions/12351771
> >
> > Release note highlights can be found here:
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65145325#ReleaseNotesMiNiFi(C++)-Versioncpp-0.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-minifi-cpp-0.13.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
>

Re: Nifi python usage

[Jeremy Dyer]

Hi,
As James mentioned in your example the "system" memory would be used by the
process/script in this case.

I wanted to add that if you use the "ExecuteScript" processor that the NiFi
memory would be used. This is because NiFi uses Jython for processing
Python files. So where a native Cython process would typically create a
heap for a Python objects in a native process, Jython will instead use the
Java heap

Jeremy Dyer

On Wed, Sep 14, 2022 at 8:36 AM James Halfpenny  wrote:

> Hi,
> The memory you allocate to NiFi will typically be the maximum heap size
> for the Java process. If you spawn a separate Python process then it will
> not be bound by the JVM heap size, so in your example it would come from
> the 8GB allocated for the “system”.
>
> I would recommend if you see high resource usage on the server again you
> take note of which processes are consuming the resources.
>
> Kind regards,
> Jim
>
> > On 14 Sep 2022, at 14:18, never more  wrote:
> >
> > Hello!
> > Can you help me with one question - can't find any information :(
> >
> > We have a nifi on my server (16 CPU, 32  RAM), in config our system adm.
> > set ram usage for nifi = 24 Gb, rest 8 Gb - for the system.
> > In Nifi we execute many Python scripts by using ExecuteStreamCommand
> (just
> > set path of script on server in properties).
> > So the question is - which resources  python script uses - Nifi (24 gb)
> or
> > system (8 gb)?
> >
> > Maybe its a little stupid question, but I am afraid that improper use
> of
> > resources may lead to a service failure,
> > because we  already  have several cases of service failure when we
> noticed
> > high utilization of resources (RAM 90-95% and CPU 80-90%)
>

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

[Jeremy Dyer]

+1, binding

source build on Ubuntu 18.04
Verified signatures
Tested simple flow, would have liked to have tested more

This process has became much more pleasant with the evolving CMake changes.
Good work!

Jeremy Dyer

On Wed, Feb 24, 2021 at 11:15 AM Ádám Markovics 
wrote:

> +1, non-binding
>
> Built and tested on Ubuntu 20.04.
> Verified checksums and signatures.
> Connected to EFM and updated with simple workflow:
> GetFile >> PutFile
> Regards,
>
> Ádám
>
> On Wed, Feb 24, 2021 at 10:48 AM Adam Debreceni 
> wrote:
> >
> > +1 (non-binding)
> >
> > Verified hashes, signatures, commit.
> > Built on Windows 10, c2-update and
> > a CWEL -> PublishKafka flow working as expected.
> >
> > Thanks,
> > Adam
> >
> > On Tue, Feb 23, 2021 at 3:59 PM Ferenc Gerlits 
> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Verified hashes and signatures.
> > > Built on (a Docker container running) Ubuntu 20.04, enabling everything
> > > except TensorFlow and JNI.
> > > Ran the binary using a simple InvokeHTTP -> LogAttribute flow yaml
> config;
> > > it worked as expected.
> > >
> > > Thanks,
> > > Ferenc
> > >
>

Re: Dynamic PropertyDescriptors

[Jeremy Dyer]

Bryan,

That makes sense. Sounds like "dependent properties" isn't quite what I'm
looking for but that is an interesting point about a customValidator. I
will try that.

As a more concrete example say a ControllerService points to a
unique database table. Depending on the ControllerService/Table selected I
would want to display all of the column names for that Table as valid
options for a PropertyDescriptor.

What I'm trying to do isn't database related but the example is pretty much
exactly the same idea.

- Jeremy Dyer

On Wed, Oct 14, 2020 at 10:52 AM Bryan Bende  wrote:

> Hello,
>
> There is an open PR for "dependent properties" which will hopefully be
> merged soon, but I think it is slightly different than what you are
> asking for.
>
> The idea is that some properties should only be shown based on how
> another property is configured, i.e. changing a strategy property to
> strategy1 should remove any properties relevant to other strategies so
> the user doesn't have to see a bunch of stuff that isn't relevant.
>
> In your scenario it isn't adding/removing whole properties, but
> updating the values of a property. Not sure that has been considered
> yet.
>
> You basically have to implement customValidate and implement logic
> that makes the processor invalid if your two properties have values
> that shouldn't be used together.
>
> -Bryan
>
> On Wed, Oct 14, 2020 at 10:27 AM Jeremy Dyer  wrote:
> >
> > Hello,
> >
> > Is it possible to have valid values for a PropertyDescriptor change based
> > on another selection?
> >
> > Ex: I have a ControllerService Property and if I change that
> > ControllerService in the dropdown I would like the valid values for
> another
> > Property to be changed in the UI.
> >
> > I'm thinking this isn't really possible since the logic occurs on the
> > backend after "Apply" has been pressed. I know I can "Apply" and
> > reconfigure to see the new values but would like something more
> immediate.
> >
> > Thanks!
> > Jeremy Dyer
>

Dynamic PropertyDescriptors

[Jeremy Dyer]

Hello,

Is it possible to have valid values for a PropertyDescriptor change based
on another selection?

Ex: I have a ControllerService Property and if I change that
ControllerService in the dropdown I would like the valid values for another
Property to be changed in the UI.

I'm thinking this isn't really possible since the logic occurs on the
backend after "Apply" has been pressed. I know I can "Apply" and
reconfigure to see the new values but would like something more immediate.

Thanks!
Jeremy Dyer

Re: In memoriam of Jeff Storck

[Jeremy Dyer]

This is shocking and heartbreaking news. Jeff was a great guy and will be
deeply missed.

The last time I saw Jeff in person was with Aldrin. We were eating at
Bonchon chicken and he was mocking me for how little spice I could handle
XD. I could always count on him for a good Dumb and Dumber reference and
laugh. We also shared a common hatred for conference food.

RIP Jeff

On Mon, Jun 15, 2020 at 2:33 PM Joe Witt  wrote:

> You will be greatly missed.  Your impact to this community has been
> tremendous.  The items Andy summarizes were huge efforts that you drove
> over periods of many many months if not a year or more and they make NiFi
> so much more accessible than before.
>
> RIP Jeff.
>
>
>
> On Mon, Jun 15, 2020 at 11:24 AM Andy LoPresto 
> wrote:
>
>> It is with a heavy heart that I write to the NiFi community today. Jeff
>> Storck, a PMC member, committer, and genuine and helpful presence in the
>> community, has passed away.
>>
>> I was lucky enough to know Jeff personally for many years, and his
>> absence is a huge loss to all of us who did. Jeff was incredibly
>> intelligent, but also kind and willing to share his experience with
>> everyone. Whether playing volleyball (I am nowhere near as good but he
>> humored me), discussing the best ramen and sushi spots, or evaluating a new
>> exercise regime, Jeff brought passion to everything. A number of us are
>> sharing stories of our favorite times with Jeff, and I am touched by how
>> many people have a memory of Jeff reaching out and patiently helping them
>> when they were new or struggling with a task.
>>
>> While other colleagues would happily transition to any topic _but_ work
>> when we went to a nearby brewery at the end of a long day, Jeff would sit
>> down next to me and say with a smile, "Ok Andy, work's done, now we can
>> _really_ talk about Groovy unit testing." He never shied away from
>> expressing his perspective and stood on conviction, but he was also open
>> and genuinely wanted to hear other views to expand his mind.
>>
>> If you come across a Spock test in the NiFi codebase, that was most
>> likely Jeff's work. He was intimately involved in much of the most
>> challenging code - especially Kerberos integration, making the difficult
>> but critical processes easier for our users. Anyone running NiFi on Java 11
>> should thank Jeff, as that was a labor of love, pushing against the
>> headwinds of so many compatibility issues and language changes. The ease
>> with which NiFi runs on multiple versions and platforms belies the immense
>> amount of effort and dedication that he put into making this happen.
>>
>> There are so many aspects to Jeff that a note like this could never
>> capture, but one that stands above the rest to me is Jeff's passion for
>> learning and growth. He devoted himself to doing the best he could and
>> constantly improving that. That is a noble philosophy that I know I will
>> remember and admire moving forward. I’ve already started learning Kotlin
>> because of Jeff’s enthusiasm and encouragement.
>>
>> Jeff’s family has created a GoFundMe page [1] and there they describe
>> their intent to celebrate his life. I think that message is very positive
>> and uplifting. To anyone wondering how they can honor Jeff's legacy, I
>> suggest offering a helping hand to someone who needs it. Something as
>> simple as responding to an extra "newbie" mailing list question at the end
>> of a long day, or taking on a challenging task because your neighbor has
>> their plate full. That's how Jeff lived, and he made the world a better
>> place.
>>
>>
>> Andy
>>
>> [1] https://www.gofundme.com/f/in-memory-of-the-awesome-jeff-storck
>>
>> Andy LoPresto
>> alopre...@apache.org
>> alopresto.apa...@gmail.com
>> He/Him
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>>

Re: Nifi tutorials

[Jeremy Dyer]

Of course! I think that would be very much appreciated by everyone.

Get Outlook for iOS

From: Russell Bateman 
Sent: Tuesday, May 26, 2020 3:30:04 PM
To: dev@nifi.apache.org 
Subject: Re: Nifi tutorials

Certainly!

On 5/26/20 12:32 PM, Anuj Jain wrote:
> Hi Team,
>
> I am currently working on Apache-Nifi in my company from past 1 year.
> I am planning to launch a series of videos for Nifi learners about what I
> have learned in Nifi in last 1 year on youtube. Am I allowed to do that?
>
>
> Regards,
> Anuj Jain
>

Re: [VOTE] Release Apache NiFi 1.11.4

[Jeremy Dyer]

+1 (binding)

Built following release helper guide.
Ran build successfully
Tested against existing instance with matching results

- Jeremy Dyer

On Fri, Mar 20, 2020 at 4:15 PM Joey Frazee 
wrote:

> +1 (non-binding)
>
> Verified checksums, signatures, and commit hash
> Ran build and all tests on Linux and OS X
> Ran flows on standalone and cluster and verified some of the
> improvements/fixes
> Built RPM profile and installed and ran
>
> -joey
> On Mar 20, 2020, 12:23 PM -0500, Marc Parisi , wrote:
> > +1 binding
> >
> > * Ran through release helper guide.
> > * Ran build and tested in clustered mode.
> > *Tested site to site with minifi java without any issues or perceived
> > leakage.
> >
> > Thanks,
> > Marc
> >
> > On Fri, Mar 20, 2020 at 10:21 AM Andrew Lim 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > -Ran full clean install on OS X (Catalina 10.15.2)
> > > -Tested secure NiFi with secure NiFi Registry 0.5.0; used NiFi Toolkit
> > > 1.11.4 to generate configuration/cert files
> > > -Ran basic flows successfully; tested basic versioned flow
> functionality
> > > -Reviewed documentation updates
> > >
> > > Drew
> > >
> > > > On Mar 18, 2020, at 1:15 PM, 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: Nifi Processor group startup along with the Nifi

[Jeremy Dyer]

It would be really cool if we offered a "hook" as part of the bootstrap
process which would allow for a script to be ran that did things like this
once NiFi was "started". Here the script could be user and environment
defined and startup the desired processors/controller services.

On Mon, Jan 6, 2020 at 4:29 PM Muazma Zahid  wrote:

> You can use Nifi CLI
> 
> for starting a processor group. We use the Nifi Registry to get the latest
> flow and then deploy and start the processor group needed.
>
> Thanks,
> Muazma
>
> On Mon, Jan 6, 2020 at 11:49 AM Hemambika Pommurapalli
>  wrote:
>
> > Hi Team,
> >
> > we have installed Nifi-1.9.2, 2-node cluster in our lab and tried to test
> > how to start the nifi processor group along with the nifi startup. Here
> is
> > the following way we tried:
> > 1. Configured nifi as a service in our lab and created the python program
> > where it contains the curl command to start the nifi process group and
> > given that is given in the execstartpost option
> > Here is the service configuration file:
> > path: /etc/systemd/system/nifi.service
> >
> > [Unit]
> > Description=Apache NiFi
> > After=network.target
> >
> > [Service]
> > Type=forking
> > User=root
> > Group=root
> > ExecStart=/opt/nifi-1.9.2/bin/nifi.sh start
> > #ExecStartPost=/usr/bin/python /root/samplecurlcode_cluster.py
> > ExecStop=/opt/nifi-1.9.2/bin/nifi.sh stop
> > ExecRestart=/opt/nifi-1.9.2/bin/nifi.sh restart
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > 
> > Can you please suggest to us do we have any other option to start the
> nifi
> > processor group along with nifi startup.
> >
> > or if need to proceed with the above way am getting the TimedOut Error
> when
> > i execute the below command.
> >
> > Command: systemctl start nifi
> > Error:
> > — nifi.service - Apache NiFi
> >Loaded: loaded (/etc/systemd/system/nifi.service; disabled; vendor
> > preset: disabled)
> >Active: failed (Result: timeout) since Mon 2020-01-06 21:21:17 IST; 2h
> > 5min ago
> >   Process: 22236 ExecStart=/opt/nifi-1.9.2/bin/nifi_start.sh
> (code=killed,
> > signal=TERM)
> >
> > Jan 06 21:19:47 nifi-1 systemd[1]: Starting Apache NiFi...
> > Jan 06 21:19:47 nifi-1 nifi_start.sh[22236]: nifi_start.sh: JAVA_HOME not
> > set; results may vary
> > Jan 06 21:19:47 nifi-1 nifi_start.sh[22236]: Java home:
> > Jan 06 21:19:47 nifi-1 nifi_start.sh[22236]: NiFi home: /opt/nifi-1.9.2
> > Jan 06 21:19:47 nifi-1 nifi_start.sh[22236]: Bootstrap Config File:
> > /opt/nifi-1.9.2/conf/bootstrap.conf
> > Jan 06 21:21:17 nifi-1 systemd[1]: nifi.service start operation timed
> out.
> > Terminating.
> > Jan 06 21:21:17 nifi-1 systemd[1]: Failed to start Apache NiFi.
> > Jan 06 21:21:17 nifi-1 systemd[1]: Unit nifi.service entered failed
> state.
> > Jan 06 21:21:17 nifi-1 systemd[1]: nifi.service failed.
> > *
> >
> > Thanks,
> > P Hemambika
> >
>

Re: OAuth2 and REST with standard processors

[Jeremy Dyer]

Mike - I needed to do this very same thing a little over 2 years ago. I
opened an initial PR https://github.com/apache/nifi/pull/2085 this PR of
course would need some work to be merged but I used it a lot on a private
branch with success. I would be a fan of seeing this approach used and can
personally vouch for it working well.

Thanks,
Jeremy Dyer

On Thu, Jan 2, 2020 at 3:18 PM Mike Thomsen  wrote:

> We have an OAuth2 resource server in our environment that provides a JWT
> back. Are there any good patterns that would work out of the box with the
> standard processor set to enable us to easily add the Authorization header
> to the outgoing REST call?
>
> If not, does anyone have any thoughts about creating a controller service
> to facilitate? Based on my limited experience here, it seems like it
> wouldn't be terribly difficult to create a service that does a client grant
> against an OAuth2 resource server and then take the access_token and make
> it available to our REST processors.
>
> Thoughts?
>
> Thanks,
>
> Mike
>

Re: NIFI-5452: Allow For Ignoring Block Locality When Writing to HDFS

[Jeremy Dyer]

David - I will take a look at this for you. However I will say here (and on
the review) that I believe the "ignorelocality" should be defaulted to
"True" by default simply to maintain functionality closer to the
original implementation.

Thanks,
Jeremy Dyer

On Mon, Oct 28, 2019 at 4:55 PM David Mollitor  wrote:

> I do apologies if I am sending a duplicate of the following message. I'm
> not sure if the first one went through...
>
> I've been working on this effort for more than a year.  I'm hoping someone
> can assist me in getting it over the finish line.
>
> PR needs a review.
>
> https://github.com/apache/nifi/pull/3652
>
> Thanks!
>

Re: MiNiFi Python Dependencies (Anaconda)

[Jeremy Dyer]

So are you saying I need to build and link against my conda python binary?

On Thu, Aug 29, 2019 at 6:47 AM Marc Parisi  wrote:

> Hi Jeremy,
>
>   Apache NiFi MiNiFi C++ python processors support virtual environments;
> however, I don't think the library links, once the binary is built, will be
> overridden through conda's environment activation ( only PATH is updated if
> I recall correctly )
>
>   I could be off base on the problem you are experiencing -- but one way
> I've solved this with my Anacaonda environment has been to use
> LD_LIBRARY_PATH. When I use the following command: export
> LD_LIBRARY_PATH=/home/0x/anaconda3/lib/
>
>   After this I no longer link to the system provided version of python
> libraries but instead to
> /home/0x/anaconda3/lib/libpython3.7m.so.1.0 .
>
>   This is actually something I've seen detected via scripts so it is
> possible for minifi.sh to (potentially) handle this.
>
>   Let me know if this solves the issue.
>
>   Best Regards,
>   Marc
>
> On Wed, Aug 28, 2019 at 8:29 PM Jeremy Dyer  wrote:
>
> > Hello all,
> >
> > I'm trying to use the MiNiFi C++ Python processors feature. I have used
> > this with great results in the past but I'm trying to load some libraries
> > that are installed in my Python conda virtual environment.
> >
> > I have activated my environment and then run the ./bin/minifi binary
> under
> > the same user but the process doesn't seem to pickup my Python library
> that
> > I am trying to import. Does anyone have any thought on how I can make my
> > virtual environment path visible to the MiNiFi agent binary so those
> > libraries can be used in MiNiFi?
> >
> > Thanks,
> > Jeremy Dyer
> >
>

Re: [discuss] approaching a NiFi 1.10.0 release

[Jeremy Dyer]

+1 looking forward to this.

I recall seeing some issues about Apache Infra and the binary size. Were
all of those appropriate modules removed as discussed and the build size
will be small enough now?

On Thu, Aug 29, 2019 at 1:35 PM Bryan Bende  wrote:

> +1 Looking forward to getting parameters and Java 11 support out there
> in a release.
>
> On Thu, Aug 29, 2019 at 1:02 PM Joe Witt  wrote:
> >
> > Team,
> >
> > It looks like we're reaching a point in which it is time to close in on
> > 1.10.
> >
> >
> https://issues.apache.org/jira/browse/NIFI-6595?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%201.10.0
> >
> > There are 250+ issues in there nearly 240 of which are already
> resolved.  I
> > haven't gone through yet for fully analyzing but the awesome Java 11 work
> > Jeff Storck and others has done means we can now build on Java 11 as well
> > as run on it.  There is a ton of great work on parameters which will make
> > managing flows at scale much easier.  We will need to drop some nars
> which
> > means we have some migration guidance to update.
> >
> > I'd like to volunteer as RM but if there are any other takers please let
> me
> > know.
> >
> > As we close in on releases this tends to create a lot of urgency to
> quickly
> > try to get new things in.  I will try to manage this well.  As always we
> > can do another release.  There is no timeline pushing us to have such
> gaps
> > between releases...we can always do another feature release.  That said,
> PR
> > review bandwidth is at a super premium.  We receive a lot more PRs than
> we
> > do receive reviews.  We'll have to work this as the PR depth grows.
> >
> > Thanks
> > Joe
>

MiNiFi Python Dependencies (Anaconda)

[Jeremy Dyer]

Hello all,

I'm trying to use the MiNiFi C++ Python processors feature. I have used
this with great results in the past but I'm trying to load some libraries
that are installed in my Python conda virtual environment.

I have activated my environment and then run the ./bin/minifi binary under
the same user but the process doesn't seem to pickup my Python library that
I am trying to import. Does anyone have any thought on how I can make my
virtual environment path visible to the MiNiFi agent binary so those
libraries can be used in MiNiFi?

Thanks,
Jeremy Dyer

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.6.1

[Jeremy Dyer]

Completely agree but isn’t MINIFICPP-786 an issue we could include as part
of that?

On Wed, Jun 26, 2019 at 6:35 PM Aldrin Piri  wrote:

> I think the intent is for this to be a fix release and wouldn’t include
> any new features.
>
> > On Jun 26, 2019, at 17:47, Jeremy Dyer  wrote:
> >
> > +1 it’s time and lots of feature bearing JIRAs have been resolved
> >
> > I do agree with with Arpad however on the inclusion of MINIFICPP-786
> >
> >> On Wed, Jun 26, 2019 at 5:37 PM Arpad Boda  wrote:
> >>
> >> Happy to take RM roles as well.
> >>
> >>> On Wed, Jun 26, 2019 at 10:30 AM Arpad Boda 
> wrote:
> >>>
> >>> +1.
> >>>
> >>>
> >>>
> >>> As this release seems to be a Windows-focused, I would also consider
> >>> adding https://issues.apache.org/jira/browse/MINIFICPP-786
> >>>
> >>> On Tue, Jun 25, 2019 at 11:53 PM Marc Parisi 
> >> wrote:
> >>>
> >>>> Hi Everyone,
> >>>>
> >>>> I wanted to discuss releasing Apache NiFi MiNiFi C++ 0.6.1 with some
> >>>> important bug fixes. We've had a few issues that impact Windows users
> >> and
> >>>> TLS with Raw Site To Site [1,2]. With these bugs addressed I think we
> >>>> should look to releasing 0.6.1.
> >>>>
> >>>> I would like to scope this bug fix release to only critical and
> blocker
> >>>> tickets found after 0.6.0. Let me know what you think or if you think
> >>>> anything else should be included that is critical to user operations.
> >>>>
> >>>>  My time is pretty fragmented but will try my best to take on RM
> duties
> >>>> unless someone would like to try their hand at it.
> >>>>
> >>>>   Thanks,
> >>>>   Marc Parisi
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/MINIFICPP-933
> >>>> [2] https://issues.apache.org/jira/browse/MINIFICPP-919
> >>>>
> >>>
> >>
>

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.6.1

[Jeremy Dyer]

+1 it’s time and lots of feature bearing JIRAs have been resolved

I do agree with with Arpad however on the inclusion of MINIFICPP-786

On Wed, Jun 26, 2019 at 5:37 PM Arpad Boda  wrote:

> Happy to take RM roles as well.
>
> On Wed, Jun 26, 2019 at 10:30 AM Arpad Boda  wrote:
>
> > +1.
> >
> >
> >
> > As this release seems to be a Windows-focused, I would also consider
> > adding https://issues.apache.org/jira/browse/MINIFICPP-786
> >
> > On Tue, Jun 25, 2019 at 11:53 PM Marc Parisi 
> wrote:
> >
> >> Hi Everyone,
> >>
> >> I wanted to discuss releasing Apache NiFi MiNiFi C++ 0.6.1 with some
> >> important bug fixes. We've had a few issues that impact Windows users
> and
> >> TLS with Raw Site To Site [1,2]. With these bugs addressed I think we
> >> should look to releasing 0.6.1.
> >>
> >>  I would like to scope this bug fix release to only critical and blocker
> >> tickets found after 0.6.0. Let me know what you think or if you think
> >> anything else should be included that is critical to user operations.
> >>
> >>   My time is pretty fragmented but will try my best to take on RM duties
> >> unless someone would like to try their hand at it.
> >>
> >>Thanks,
> >>Marc Parisi
> >>
> >> [1] https://issues.apache.org/jira/browse/MINIFICPP-933
> >> [2] https://issues.apache.org/jira/browse/MINIFICPP-919
> >>
> >
>

Re: First contribution - did I do it right?

[Jeremy Dyer]

Evan - Its always refreshing to see people so excited to be involved and
contribute! Thank you! I feel certain this sort of enthusiasm will help get
eyes on your PR from the community much more quickly. Thanks again and keep
at it!

On Wed, Jun 5, 2019 at 8:08 PM Evan Reynolds 
wrote:

> Perfect - that's all I needed to know, and I figured it would be a while
> before someone had time to go over it. No worries!!
>
> I might go ahead and look to see if I can figure out the other issues,
> then - if nothing else, it's being kind of fun! :-)
>
> -Evan
>
>
> Bryan Bende wrote on 6/5/19 3:10 PM:
>
> Generally opening a JIRA and submitting a PR is all there is to it. You can
> also put the jira in the “patch available” state, although this was
> originally used more before we used GitHub, when people actually attached
> patches to JIRAs, but technically a PR is still an available patch.
>
> Getting a reviewer can sometimes be tough... there are lots of
> contributions (a good thing), but only so many reviewers, and then within
> the reviewers only a few of them are probably familiar with the part of the
> code being changed, so it can take some time for one of them to be free.
>
> We appreciate anything you choose to contribute, and it’s totally fine to
> submit several different pull requests, unless there is some order of
> changes that needs to occur.
>
> Hope that helps.
>
> -Bryan
>
> On Wed, Jun 5, 2019 at 5:48 PM Evan Reynolds  
> 
> wrote:
>
>
> Thanks for the fast reply!
>
> When I saved the JIRA it told me the ticket wasn't visible - though today
> it is, so either I guessed at the right field to fill out or else it just
> took time? I'm not sure, but either way ... good! :-D
>
> But I also wasn't sure if should I do anything to draw attention to it so
> that someone knows it's ready for a code review? I don't expect a review to
> happen immediately, don't get me wrong. But with a popular project with a
> lot of filed tickets I didn't know how to stand out as having a proposed
> code fixes ready!
>
> Thanks again - I really appreciate it the time.
>
> -Evan
>
>
>
> On Wed, Jun 5, 2019 at 2:08 PM Bryan Bende  
>  wrote:
>
>
> Hi Evan,
>
> It looks correct to me. What did you mean by 'the ticket is not visible"?
> I was able to view the JIRA.
>
> Thanks,
>
> Bryan
>
> On Wed, Jun 5, 2019 at 4:59 PM Evan Reynolds  
> 
> wrote:
>
>
> I had a problem with the MergeRecord processor which I tracked down to a
> bug, so I fixed it. I thought I'd create a ticket and submit that back
>
> up,
>
> but the ticket says it isn't visible and I am not sure if I did
>
> something
>
> wrong or if that's expected until the Jira is reviewed? The
>
> contributor's
>
> guide (which is amazingly helpful!) didn't have much on that!
>
>
> So I thought I'd ask - did I do this correctly? There are a few other
> things I'd love to track down and fix but I figured I'd get one through
> before looking for more!
> https://issues.apache.org/jira/browse/NIFI-6349
> (and the git pull request is linked in the ticket)
>
> Thank you - and I hope it was appropriate to ask here about it!
>
>
>
> ---
>
> Evan reynoldse...@usermind.com
>
>   [image: cid:image001.jpg@01CB64D2.4D120F10]
>
>
>
>
> --
>
>
>
> ---
>
> Evan Reynolds
> e...@usermind.com
>
>   [image: cid:image001.jpg@01CB64D2.4D120F10]
>
>

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

[Jeremy Dyer]

Congratulations Peter!

On Thu, May 30, 2019 at 2:58 PM Jeff  wrote:

> Welcome to the PMC, Peter!  Congrats!
>
> On Thu, May 30, 2019 at 2:45 PM Tony Kurc  wrote:
>
> > 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 MiNiFi C++ 0.6.0 (RC2)

[Jeremy Dyer]

+1, binding

   - Verified all checksums
   - Configured via CMake without bootstrap.sh
   - Configured and built with bootstrap.sh
   - Validated base build
   - Validated build with all extensions enabled on CentOs 7.6 and Ubuntu
   18.04
   - Validated base build on OS X 10.14.3
   - Validated base build on Ubuntu 16.04
   - Validated base build on Ubuntu 18.04
   - Verified LICENSE and README look good

Thank you for getting this RC together. I have for one have been following
this release closely and am very excited for the new JNI integrations,
native Python processors, and CoAP support.

On Wed, Mar 20, 2019 at 8:10 AM Arpad Boda  wrote:

> +1
>
>
>
> -Verified checksums, signature, commit ID
>
> -Built on Ubuntu 16 and OS X 10.13 (executed all tests on both systems)
>
> -Verified MiNiFi and some Nanofi examples to start and work as expected
>
> -LICENSE found a looks good to me
>
> -NOTICE found, but should be updated:
>
> Apache NiFi MiNiFi
>
> Copyright 2017 The Apache Software Foundation
>
> -README.md found a looks good to me, contains a minor typo for Bionic:
>
> | Ubuntu 16  | make u18 | nifi-minifi-cpp-bionic-$VERSION-bin.tar.gz
>
>
>
>
>
> On 19/03/2019, 20:59, "Aldrin Piri"  wrote:
>
>
>
> +1, binding
>
>
>
> So much great stuff in this release.  Thanks for RMing, Marc!
>
>
>
> comments:
>
> Signature and hashes looked good
>
> Verified build, tests, and linter looked good on Ubuntu 18 and OS X
> 10.13
>
> Performed builds using the make targets {u16, u18, centos, debian,
> fedora}
>
> to generate successful assemblies
>
> Verified a sampling of the assemblies on different platforms and
> worked as
>
> expected for a variety of flows and functionalities
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 19, 2019 at 12:52 PM Marc Parisi 
> wrote:
>
>
>
> > Hello Apache NiFi community,
>
> >
>
> > I am pleased to call this vote for the source release of Apache NiFi
> MiNiFi
>
> > C++ 0.6.0
>
> >
>
> > The source tar.gz, including signatures, digests, and convenience
> binaries.
>
> > can be found at:
>
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.6.0-rc2/
>
> >
>
> > The Git tag is minifi-cpp-0.6.0-RC2
>
> > The Git commit ID is 28ade6cf75e8a0ccce78699f147f4ad9baaf70c2
>
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=
>
> > <
>
> >
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=28ade6cf75e8a0ccce78699f147f4ad9baaf70c2
>
> > >
>
> > 28ade6cf75e8a0ccce78699f147f4ad9baaf70c2
>
> >
>
> > Checksum of nifi-minifi-cpp-0.6.0-source.tar.gz:
>
> > SHA256:
> 65c5ecf4b8ce807e982ed4dcb11472f574f62e66bfeeaa3348b0852c926175c3
>
> > SHA512:
>
> >
>
> >
> 4c53275b6b595fe1a17f6ad54a4aaa831b45044f3f8a5ad204475d3beb8fde441fc28d4a385d8804ed28f7934e37d45a01ab130b5241baa414a7c788f23e4451
>
> >
>
> > Release artifacts are signed with the following key:
>
> > https://people.apache.org/keys/committer/phrocker.asc
>
> >
>
> > KEYS file available here:
>
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> >
>
> > 142 issues were closed/resolved for this release:
>
> >
>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321520=12343363
>
> >
>
> > Release note highlights can be found here:
>
> >
>
> >
> https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.6.0
>
> >
>
> > The vote will be open for 72 hours.
>
> > Please download the release candidate and evaluate the necessary
> items
>
> > including checking hashes, signatures, build
>
> > from source, and test.  The please vote:
>
> >
>
> > [ ] +1 Release this package as nifi-minifi-cpp-0.6.0
>
> > [ ] +0 no opinion
>
> > [ ] -1 Do not release this package because because...
>
> >
>
>
>

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

[Jeremy Dyer]

+1 (binding)

Verified signature, hashes. Build succeeded with contrib-check
Started NiFi up and tested S3 and GCS processors.
Also tested auto loading of nars without restart

> On Mar 13, 2019, at 11:00 PM, Nathan Gough  wrote:
> 
> +1 (non-binding)
> 
> - Verified signature
> - Verified checksums
> - mvn contrib executed successfully
> - Created simple test flow in both standalone and clustered modes, secure
> and insecure
> - Checked license and readme files
> 
> Nathan
> 
> 
> 
> On Wed, Mar 13, 2019 at 6:33 PM Arpad Boda  wrote:
> 
>> +1
>> 
>> -Verified signature
>> -Verified checksum
>> -Built, executed tests
>> -Created a simple flow
>> -Sent flow files both using raw and HTTP S2S, verified them.
>> 
>> On 13/03/2019, 22:24, "Rob Fellows" 
>> wrote:
>> 
>>+1
>> 
>>Went through the Release Helper Guide.
>>Started the app and created a simple data flow. It seemed good to me.
>> 
>>Thanks,
>>Rob
>> 
>>On Wed, Mar 13, 2019 at 3:16 PM Mark Payne 
>> wrote:
>> 
>>> +1 (binding)
>>> 
>>> Verified signature, hashes. Build succeeded with contrib-check and
>> grpc
>>> profiles.
>>> Started app and performed some basic functionality testing and all
>> seemed
>>> correct.
>>> 
>>> Thanks
>>> -Mark
>>> 
 On Mar 13, 2019, at 1:49 AM, 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...
>>> 
>>> 
>> 
>>--
>>Thanks,
>>Rob Fellows
>> 
>> 
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Nathan Gough

[Jeremy Dyer]

Congratulations Nathan!

On Thu, Jan 3, 2019 at 6:52 AM Mike Thomsen  wrote:

> Congratulations!
>
> On Thu, Jan 3, 2019 at 6:51 AM Otto Fowler 
> wrote:
>
> > Congratulations Nathan!
> >
> >
> > On January 2, 2019 at 21:30:42, Tony Kurc (tk...@apache.org) wrote:
> >
> > 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: [ANNOUNCE] New Apache NiFi Committer Ed Berezitsky

[Jeremy Dyer]

Congratulations Ed!

On Thu, Jan 3, 2019 at 6:52 AM Mike Thomsen  wrote:

> Congratulations!
>
> On Thu, Jan 3, 2019 at 6:50 AM Otto Fowler 
> wrote:
>
> > Congratulations Ed!
> >
> >
> > On January 2, 2019 at 21:36:45, Tony Kurc (tk...@apache.org) wrote:
> >
> > 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
> >
>

Re: [VOTE] Release Apache NiFi 1.8.0

[Jeremy Dyer]

+1, binding

Validated signatures, hashes, and commit
Validated existing workflows against a NiFi Registry instance

Lots of good stuff!
Jeff thanks for handling the release!

- Jeremy Dyer

On Thu, Oct 18, 2018 at 5:11 PM Pierre Villard 
wrote:

> +1, binding
>
> Checked signature, hashes, L and commit.
> Ran multiple workflows in both secured and unsecured clusters.
> Played with the new load-balancing and offloading features (AWESOME
> WORK!!!)
> Confirmed some minor fixes and improvements.
>
> A great release!
> Thanks Jeff for taking care of the RM duties and thanks to all the people
> contributing in this release!
>
> Pierre
>
> Le jeu. 18 oct. 2018 à 20:33, Otto Fowler  a
> écrit :
>
> > +1
> >
> > Confirmed signatures
> > Confirmed hashes
> > Confirmed source matches commit src
> > ran build withe check
> > ran nifi with a template from a bug to verify fix
> >
> >
> >
> >
> > On October 18, 2018 at 09:45:12, Joe Witt (joe.w...@gmail.com) wrote:
> >
> > +1 (binding)
> >
> > Confirmed sigs, hashes, source L, and specified commit present
> > (including Drew's doc update which is the last code change)
> > Confirmed full clean build with contrib check and grpc on clean
> repo/etc..
> > Tested local nifi instance and sample flows. Did not test full secure
> > setup with clustering.
> >
> > This release has quietly turned out to be another beast and the new
> > load balancing capabilities are awesome!
> >
> > Thanks
> > On Thu, Oct 18, 2018 at 7:57 AM Mike Thomsen 
> > wrote:
> > >
> > > (NOTICE, LICENSE and README all looked good when I looked at them; no
> > > problems were apparent)
> > >
> > > On Thu, Oct 18, 2018 at 7:56 AM Mike Thomsen 
> > wrote:
> > >
> > > > +1 binding.
> > > >
> > > > - Checksums and branch id/diff matched up.
> > > > - Ran binary against a Mongo regression test that I made for the new
> > > > client service functionality and everything worked cleanly against
> > > > dockerized Mongo.
> > > >
> > > > On Wed, 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...
> > > >>
> > > >
> >
>

Re: [VOTE] Release Apache NiFi Registry 0.3.0

[Jeremy Dyer]

+1 binding

Validated hashes, build, sample run to create bucket and save flow,
validated eventing filter, and REGISTRY_START event presence.

Comment: Small typo in release guide stating nifi-registry-0.2.0 instead of
nifi-registry-0.3.0 just be aware if copying and pasting commands. No big
deal.

On Sat, Sep 22, 2018 at 9:54 AM Kevin Doran  wrote:

> Hello,
>
> I am pleased to call this vote for the source release of Apache NiFi
> Registry 0.3.0.
>
> The source zip, including signatures, digests, etc. can be found at:
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/
>
> The Git tag is nifi-registry-0.3.0-RC1
> The Git commit ID is 2fef9fac2b627ee1f3428b07019b333c68f65f2d
>
> https://git-wip-us.apache.org/repos/asf?p=nifi-registry.git;a=commit;h=2fef9fac2b627ee1f3428b07019b333c68f65f2d
>
> Checksums of nifi-registry-0.3.0-source-release.zip:
> SHA1:   4340068ef7e3ba099f614b86be4d2d77016845d9
> SHA256: c0a51f6b5855202993daa808015ddf26466843f3bc5727333f44661099c2ad5b
> SHA512:
> efc9882511eaccca4cc83117f5a870859f80b3667d8d3d9bf6e1fec9a1e4d1f37abee4476aaa28245468eca0eec30a3e84eba8e547a0fc1a97fdf6c289ab8b96
>
> Release artifacts are signed with the following key:
> Fingerprint = C09B A891 AED4 5B8C 2C23  1AFE 1FB6 6A91 F71B 6207
> Available at:
> https://people.apache.org/keys/committer/kdoran.asc
> https://pgp.mit.edu/pks/lookup?op=get=0x1FB66A91F71B6207
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/dev/nifi/KEYS
>
> 15 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343483=Html=12320920
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
>
> 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-${VERSION}
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: Apache NiFi Registry 0.3.0 RC1 Release Helper Guide

[Jeremy Dyer]

The sad part is I noticed that when making the draft and forgot to change
it in that brief 5 minute window =) I'll send it to the appropriate vote
thread now

On Sun, Sep 23, 2018 at 2:54 PM Joe Witt  wrote:

> this is just the helper thread jeremy.  youll want to resend on vote thread
>
> On Sun, Sep 23, 2018, 11:23 AM Jeremy Dyer  wrote:
>
> > +1 binding
> >
> > Validated hashes, build, sample run to create bucket and save flow,
> > validated eventing filter, and REGISTRY_START event presence.
> >
> > Comment: Small typo in release guide stating nifi-registry-0.2.0 instead
> of
> > nifi-registry-0.3.0 just be aware if copying and pasting commands. No big
> > deal.
> >
> > On Sat, Sep 22, 2018 at 10:13 AM Kevin Doran  wrote:
> >
> > > Hello Apache NiFi community,
> > >
> > > Please find the associated guidance to help those interested in
> > > validating/verifying the Apache NiFi Registry release so they can vote.
> > >
> > > # Download latest KEYS file:
> > > https://dist.apache.org/repos/dist/dev/nifi/KEYS
> > >
> > > # Import keys file:
> > > gpg --import KEYS
> > >
> > > # [optional] Clear out local maven artifact repository
> > >
> > > # Pull down nifi-registry-0.3.0 source release artifacts for review:
> > >
> > > wget
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip
> > > wget
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.asc
> > > wget
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha1
> > > wget
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha256
> > > wget
> > >
> >
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha512
> > >
> > > # Verify the signature
> > > gpg --verify nifi-registry-0.3.0-source-release.zip.asc
> > >
> > > # Verify the hashes (sha1, sha256, sha512) match the source and what
> > > was provided in the vote email thread
> > > shasum -a 1 nifi-registry-0.3.0-source-release.zip
> > > shasum -a 256 nifi-registry-0.3.0-source-release.zip
> > > shasum -a 512 nifi-registry-0.3.0-source-release.zip
> > >
> > > # Unzip nifi-registry-0.3.0-source-release.zip
> > >
> > > # Verify the build works including release audit tool (RAT) checks
> > > cd nifi-registry-0.2.0
> > > mvn clean install -Pcontrib-check
> > >
> > > # Verify the contents contain a good README, NOTICE, and LICENSE.
> > >
> > > # Verify the git commit ID is correct
> > >
> > > # Verify the RC was branched off the correct git commit ID
> > >
> > > # Look at the resulting convenience binary as found in
> > > nifi-registry-assembly/target
> > >
> > > # Make sure the README, NOTICE, and LICENSE are present and correct
> > >
> > > # Run the resulting convenience binary and make sure it works as
> expected
> > >
> > > # Test integration between the Registry and NiFi
> > >
> > > Start the registry
> > >
> > > ./bin/nifi-registry.sh start
> > >
> > > Create a bucket in the registry
> > >
> > > - Go to the registry UI at http://localhost:18080/nifi-registry
> > > - Click the tool icon in the top right corner
> > > - Click New Bucket from the bucket table
> > > - Enter a name and click create
> > >
> > > Start NiFi
> > >
> > > Tell NiFi about your local registry instance
> > >
> > > - Go the controller settings for NiFi from the top-right menu
> > > - Select the Registry Clients tab
> > > - Add a new Registry Client giving it a name and the url of
> > > http://localhost:18080
> > >
> > > Create a process group and place it under version control
> > >
> > > - Right click on the PG and select the Version menu
> > > - Select Start Version Control
> > > - Choose the registry instance and bucket you want to use
> > > - Enter a name, description, and comment
> > >
> > > Go back to the registry and refresh the main page and you should see
> > > the versioned flow you just saved
> > >
> > > Import a new PG from a versioned flow
> > >
> > > - Drag on a new PG like normal
> > > - Instead of entering a name, click the Import link
> > > - Now choose the flow you saved before
> > >
> > > You should have a second identical PG now.
> > >
> > > # 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!
> > >
> >
>

Re: Apache NiFi Registry 0.3.0 RC1 Release Helper Guide

[Jeremy Dyer]

+1 binding

Validated hashes, build, sample run to create bucket and save flow,
validated eventing filter, and REGISTRY_START event presence.

Comment: Small typo in release guide stating nifi-registry-0.2.0 instead of
nifi-registry-0.3.0 just be aware if copying and pasting commands. No big
deal.

On Sat, Sep 22, 2018 at 10:13 AM Kevin Doran  wrote:

> Hello Apache NiFi community,
>
> Please find the associated guidance to help those interested in
> validating/verifying the Apache NiFi Registry release so they can vote.
>
> # Download latest KEYS file:
> https://dist.apache.org/repos/dist/dev/nifi/KEYS
>
> # Import keys file:
> gpg --import KEYS
>
> # [optional] Clear out local maven artifact repository
>
> # Pull down nifi-registry-0.3.0 source release artifacts for review:
>
> wget
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip
> wget
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.asc
> wget
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha1
> wget
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha256
> wget
> https://dist.apache.org/repos/dist/dev/nifi/nifi-registry/nifi-registry-0.3.0/nifi-registry-0.3.0-source-release.zip.sha512
>
> # Verify the signature
> gpg --verify nifi-registry-0.3.0-source-release.zip.asc
>
> # Verify the hashes (sha1, sha256, sha512) match the source and what
> was provided in the vote email thread
> shasum -a 1 nifi-registry-0.3.0-source-release.zip
> shasum -a 256 nifi-registry-0.3.0-source-release.zip
> shasum -a 512 nifi-registry-0.3.0-source-release.zip
>
> # Unzip nifi-registry-0.3.0-source-release.zip
>
> # Verify the build works including release audit tool (RAT) checks
> cd nifi-registry-0.2.0
> mvn clean install -Pcontrib-check
>
> # Verify the contents contain a good README, NOTICE, and LICENSE.
>
> # Verify the git commit ID is correct
>
> # Verify the RC was branched off the correct git commit ID
>
> # Look at the resulting convenience binary as found in
> nifi-registry-assembly/target
>
> # Make sure the README, NOTICE, and LICENSE are present and correct
>
> # Run the resulting convenience binary and make sure it works as expected
>
> # Test integration between the Registry and NiFi
>
> Start the registry
>
> ./bin/nifi-registry.sh start
>
> Create a bucket in the registry
>
> - Go to the registry UI at http://localhost:18080/nifi-registry
> - Click the tool icon in the top right corner
> - Click New Bucket from the bucket table
> - Enter a name and click create
>
> Start NiFi
>
> Tell NiFi about your local registry instance
>
> - Go the controller settings for NiFi from the top-right menu
> - Select the Registry Clients tab
> - Add a new Registry Client giving it a name and the url of
> http://localhost:18080
>
> Create a process group and place it under version control
>
> - Right click on the PG and select the Version menu
> - Select Start Version Control
> - Choose the registry instance and bucket you want to use
> - Enter a name, description, and comment
>
> Go back to the registry and refresh the main page and you should see
> the versioned flow you just saved
>
> Import a new PG from a versioned flow
>
> - Drag on a new PG like normal
> - Instead of entering a name, click the Import link
> - Now choose the flow you saved before
>
> You should have a second identical PG now.
>
> # 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!
>

Re: [DISCUSS] Stale PRs

[Jeremy Dyer]

Andy - That’s a good point. What I had in my mind was sort of like this 

- After 30 days alert is sent to author if no activity/comment not just 
commits.They would still have something like a week
- If code is complicated they don’t have to finish it just simply comment on PR 
to stop it from being closed
- I like this because when they comment they can say things like. “Sorry this 
is taking longer because of problem XYZ I’m having” others in the community can 
see this and offer input so it helps on collaboration
- This also helps people watching the PRs and interested in using them have a 
much more clear and accurate understanding of where the PR actually stands 
progress wise so they can more accurately determine when it will be available 
to them
- To your last point, which is a good one, they would simply comment with a 
gentle reminder that they would like for someone to review.

Thoughts? I’m sure I’m missing something there but that’s sort of how I imagine 
it working

- Jeremy Dyer

Thanks - Jeremy Dyer


From: Andy LoPresto 
Sent: Saturday, September 15, 2018 11:57 AM
To: dev@nifi.apache.org
Subject: Re: [DISCUSS] Stale PRs

Jeremy,

What about in the scenario where the submitter does everything and we (the 
committers) are slow? I’m not saying we shouldn’t try to fix all the problems, 
just that I see a lot more of the latter happening.

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69

> On Sep 15, 2018, at 08:51, Pierre Villard  wrote:
>
> Andy,
>
> Totally get your points. I imagine that introducing this approach would
> help keeping dynamic exchanges on pull requests.
>
> In case a PR needs complex/time consuming work (or in case the author is
> just not in a position to process comments), I think we could have two
> approaches:
> - the PR is considered stale after 60 days but is actually closed one week
> later. I think it leaves time for someone (ideally the author) to comment
> and give an update so that the PR is not considered stale anymore, no?
> - for important PRs, it's possible to "remove" this mechanism using
> specific labels but I guess we would have to ask ASF infra if we want to
> have rights to add labels on PRs (?)
>
> Pierre
>
>
>
>
> Le sam. 15 sept. 2018 à 17:44, Andy LoPresto  a
> écrit :
>
>> Pierre,
>>
>> I’m going to delay my response on that proposal while I ask for (aka
>> should gather on my own) some information. Is that really our problem? By
>> that, I mean are stale PRs where we are getting bogged down? I am sure
>> there are some old ones that should be closed out. My larger concern is
>> that even new PRs don’t get reviewed immediately for a number of reasons.
>>
>> 1. Balance of committers to submissions. As the project continues to grow,
>> we have far more people providing code than can review it.
>> 2. Quality of PR. Not that the code is necessarily bad, but the PR doesn’t
>> clearly explain the problem and how they are solving it, provide test
>> cases, provide templates or a Docker container if interacting with an
>> external service, etc. All of these things add up to make the cost of
>> reviewing higher.
>> 3. What PRs cover. Previously, there was still a lot of low-hanging fruit,
>> and less complexity. While the project is still fairly cleanly organized,
>> many PRs now are less “add this simple functionality” and more “improve
>> this complicated feature.”
>>
>> I guess I would not have a problem with your proposal, but I do wonder if
>> there are more effective ways to reduce the backlog by identifying other
>> areas of improvement.
>>
>> Andy LoPresto
>> alopre...@apache.org
>> alopresto.apa...@gmail.com
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>>> On Sep 15, 2018, at 08:33, Pierre Villard 
>> wrote:
>>>
>>> Hi,
>>>
>>> The number of open PRs is still growing and it could make think people
>> that
>>> the project is not healthy/active (even though a quick look at the last
>>> commit date or the commits rate is a clear indication that the project is
>>> healthy).
>>>
>>> In order to encourage people to review code and keep active discussions
>> on
>>> the PRs, I suggest to find a way to keep this number as small as
>> possible.
>>> To do so, I'd like to ask the wider community if the approach taken by a
>>> project like Apache Beam would be a good idea:
>>>
>>> "A pull request becomes stale after its author fails to respond to
>>> actionable comments for 60 days. Author of a closed pull request is
>> welcome
>>> to reopen the same pull request again in the future."
>>>
>>> This approach is managed by a file [1] in the .github directory of the
>>> repository.
>>>
>>> What do you think about this approach?
>>>
>>> [1] https://github.com/apache/beam/blob/master/.github/stale.yml
>>>
>>> Pierre
>>

Contrib Check Test Failures on master

[Jeremy Dyer]

Team - I'm experiencing test failures on master. I was formulating a PR and
noticed the failures when running -P contrib-check (this wasn't surprising
as I often have them =) however on further inspection I noticed its
happening on master as well. I see the failure of this test. Seems like
something isn't quite right there and that message leads me to believe that
my local machine should maybe even be skipping this test?

[INFO] Running
org.apache.nifi.cluster.firewall.impl.FileBasedClusterNodeFirewallTest
[ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.1
s <<< FAILURE! - in
org.apache.nifi.cluster.firewall.impl.FileBasedClusterNodeFirewallTest
[ERROR]
ensureBadDataWasIgnored(org.apache.nifi.cluster.firewall.impl.FileBasedClusterNodeFirewallTest)
Time elapsed: 0.008 s  <<< FAILURE!
java.lang.AssertionError: firewall treated our malformed data as a host. If
`host "bad data should be skipped"` works locally, this test should have
been skipped.
at
org.apache.nifi.cluster.firewall.impl.FileBasedClusterNodeFirewallTest.ensureBadDataWasIgnored(FileBasedClusterNodeFirewallTest.java:86)

Re: [ANNOUNCE] New NiFi PMC member Jeremy Dyer

[Jeremy Dyer]

I am very excited to be more involved in such a great community! Thank you
everyone for the kind words and looking forward to what the future brings
in this community!

Thanks!
Jeremy Dyer

On Wed, Aug 1, 2018 at 8:46 AM, Yolanda Davis 
wrote:

> Congratulations Jeremy!
>
> On Wed, Aug 1, 2018 at 7:23 AM, Rob Moran  wrote:
>
> > Congratulations, Jeremy!
> >
> > On Tue, Jul 31, 2018 at 1:17 PM Sivaprasanna 
> > wrote:
> >
> > > Congratulations, Jeremy. Well deserved.
> > >
> > > On Tue, 31 Jul 2018 at 9:44 PM, Scott Aslan 
> > wrote:
> > >
> > > > Congrats Jeremy!
> > > >
> > > > On Tue, Jul 31, 2018 at 11:02 AM Michael Moser 
> > > wrote:
> > > >
> > > > >  Congrats, welcome, and thank you for your work.
> > > > >
> > > > >
> > > > > On Tue, Jul 31, 2018 at 9:21 AM Otto Fowler <
> ottobackwa...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Congratulations!
> > > > > >
> > > > > >
> > > > > > On July 31, 2018 at 08:36:48, Tony Kurc (tk...@apache.org)
> wrote:
> > > > > >
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> --
> yolanda.m.da...@gmail.com
> @YolandaMDavis
>

Advice on connecting single NiFi instance to new cluster

[Jeremy Dyer]

Team - I'm sitting up a small development environment. I have an existing
NiFi instance that is pointed to a NiFi-Registry instance and its running
several versioned flows. I wanted to join this instance with a cluster of 2
other nifi nodes. The 2 new nodes are fresh instances all running Nifi
1.7.0. However since the existing instance is already running flows it
fails to join the new cluster because obviously the new nodes do not have
anything running yet. What I really want is to be able to bootstrap those 2
new nodes with the same flows running on the existing instance but I can't
seem to get that to work (boot fails and complains about the flows not
being the same) however since I'm using the NiFi-Registry I'm not sure the
best path forward?

I realize that I could just wipe everything and start over but I wanted to
try and solve the problem and maybe improve the documentation along the way
to help others that might be having the same issue. Long story short what
is the best way to get out of the pickle I'm in?

Thanks,
Jeremy Dyer

[ANNOUNCE] Apache NiFi MiNiFi 0.5.0 release

[Jeremy Dyer]

The Apache NiFi team would like to announce the release of Apache NiFi
MiNiFi 0.5.0.

Apache NiFi is an easy to use, powerful, and reliable system to process and
distribute data.  Apache NiFi was made for dataflow.  It supports highly
configurable directed graphs of data routing, transformation, and system
mediation logic.

MiNiFi is a subproject of Apache NiFi.  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.

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

Maven artifacts have been made available here:
https://repository.apache.org/content/repositories/releases/org/apache/nifi/
minifi

Issues closed/resolved for this list can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921=12342658

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Version0.5.0

Thank you
The Apache NiFi team

[RESULT][VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Jeremy Dyer]

Apache NiFi Community,

I am pleased to announce that the 0.5.0 release of Apache NiFi MiNiFi
passes with
  7 +1 (binding) votes
  0 -1 (binding) votes
  2 +1 (non-binding) votes
  0 -1 (non-binding) votes

Thanks to all who helped make this release possible.

Here is the PMC vote thread:
https://lists.apache.org/thread.html/0d6a82bfc420a5d7739881a55db8eaed848e09e3ca618e7bb8118fa4@%3Cdev.nifi.apache.org%3E

Re: Status of nifi-docker

[Jeremy Dyer]

Mike - Yes both of them are used. The dockerhub one is obviously pushed to 
dockerhub (and built there hence the separate file) and the dockermaven one is 
built locally for anyone who wishes to do so. I know I use the dockermaven one 
all the time for development purposes

Thanks,
Jeremy Dyer

Thanks - Jeremy Dyer

From: Pierre Villard 
Sent: Friday, June 29, 2018 10:11:31 AM
To: dev
Subject: Re: Status of nifi-docker

Wrong copy/paste... thread with title Question on Docker module
<https://mail-archives.apache.org/mod_mbox/nifi-dev/201806.mbox/ajax/%3CCAGvqHsdf5fNuC2mGwmGWZRjQ3_T5W_MqtyB9KY9k7JGpEaL8yQ%40mail.gmail.com%3E>


2018-06-29 16:10 GMT+02:00 Pierre Villard :

> Hi Mike,
>
> Have a look on this thread: https://mail-archives.apache.
> org/mod_mbox/nifi-dev/201806.mbox/browser
>
> Pierre
>
> 2018-06-29 15:59 GMT+02:00 Mike Thomsen :
>
>> We appear to have two copies of the Docker builds. One in dockerhub and
>> one
>> in dockermaven. Do we use both of them? I need to know so I can try to
>> finish up a PR to expose ZK-based clustering w/ Docker.
>>
>> Thanks,
>>
>> Mike
>>
>
>

Apache NiFi MiNiFi 0.5.0 RC2 Release Helper Guide

[Jeremy Dyer]

Hello Apache NiFi community,

Please find the associated guidance to help those interested in
validating/verifying the release so they can vote.

# Download latest KEYS file:
  https://dist.apache.org/repos/dist/dev/nifi/KEYS

# Import keys file:
  gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down minifi-0.5.0 source release artifacts for review:

  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.asc
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha1
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha256

# Verify the signature
  gpg --verify minifi-0.5.0-source-release.zip.asc

# Verify the hashes (sha1 and sha256) match the source and what was
provided in the vote email thread
  sha1sum minifi-0.5.0-source-release.zip
  sha256sum minifi-0.5.0-source-release.zip

# Unzip minifi-0.5.0-source-release.zip

# Verify the build works including release audit tool (RAT) checks
  cd minifi-0.5.0
  mvn clean install -Pcontrib-check

# 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


There are three convenience binaries generated as part of this process.
The MiNiFi assembly, a MiNiFi Toolkit assembly, and a MiNiFi C2 Assembly.

For the MiNiFi assembly:

# Look at the resulting convenience binary as found in
minifi-assembly/target

# Make sure the README, NOTICE, and LICENSE are present and correct

# Run the resulting convenience binary and make sure it works as expected


For the MiNiFi Toolkit assembly:

# Look at the resulting convenience binary as found in
minifi-toolkit/minifi-toolkit-assembly/target

# Make sure the README, NOTICE, and LICENSE are present and correct

# Run the resulting convenience binary and make sure it works as expected


For the MiNiFi C2 assembly:

# Look at the resulting convenience binary as found in
minifi-c2/minifi-c2-assembly/target

# Make sure the README, NOTICE, and LICENSE are present and correct

# Run the resulting convenience binary and make sure it works as expected



# Send a response to the vote thread indicating a +1, 0, -1 based on your
findings.


Thank you for your time and effort to validate the release!

[VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Jeremy Dyer]

Hello,

I am pleased to call this vote for the source release of Apache NiFi MiNiFi
minifi-0.5.0 RC2.

The source zip, including signatures, digests, etc. can be found at:
*https://repository.apache.org/content/repositories/orgapachenifi-1130/
*

The Git tag is minifi-0.5.0-RC2
The Git commit ID is 05f516d3da33a0547ccfad342414504cdacd4a68
*https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=05f516d3da33a0547ccfad342414504cdacd4a68
*
*https://github.com/apache/nifi-minifi/commit/05f516d3da33a0547ccfad342414504cdacd4a68
*

wget
https://repository.apache.org/content/repositories/orgapachenifi-1130/org/apache/nifi/minifi/minifi/0.5.0/minifi-0.5.0-source-release.zip

Checksums of minifi-0.5.0-source-release.zip:
SHA1: be624db030aedd5c249e58c4c57d55ca917cd6ea
SHA256: 1f96ca7d8c2f52f9c15dad532065163f14cb01a2edbc783d4faa33656ff5ab88

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/jeremydyer.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

16 issues were closed/resolved for this release:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921=12342658
*

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/MINIFI/Release+
Notes#ReleaseNotes-Version0.5.0

The vote will be open until 2:00PM EDT, 1 July 2018.

Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build
from source, and test.  Then please vote:

[ ] +1 Release this package as minifi-0.4.0
[ ] +0 no opinion
[ ] -1 Do not release this package because...

Thanks!

[CANCEL][VOTE] Release Apache NiFi MiNiFi 0.5.0

[Jeremy Dyer]

Thanks for catching that Aldrin. Given this I'm going to cancel this RC1
and then after MINIFI-460 is resolved I will kick out RC2.

Thanks

On Thu, Jun 28, 2018 at 10:05 AM, Aldrin Piri  wrote:

> Hi Jeremy,
>
> Through the course of validation, I also saw an issue with dependencies in
> support of the SiteToSite Prov Reporting Task.  This should be resolved
> before release.  I would be in favor of an RC2 to remedy the hash issues as
> well as incorporate a fix for the aforementioned issue, filed as MINIFI-460
> [1].
>
> [1] https://issues.apache.org/jira/browse/MINIFI-460
>
> On Thu, Jun 28, 2018 at 9:36 AM Aldrin Piri  wrote:
>
> > Build was okay but looks like the hashes aren't matching for the
> artifacts
> > in the ASF repo and those in the email.
> >
> > On Tue, Jun 26, 2018 at 4:12 PM Jeremy Dyer 
> wrote:
> >
> >> Hello,
> >>
> >> I am pleased to call this vote for the source release of Apache NiFi
> >> MiNiFi
> >> minifi-0.5.0.
> >>
> >> The source zip, including signatures, digests, etc. can be found at:
> >> *https://repository.apache.org/content/repositories/orgapachenifi-1129/
> >> <https://repository.apache.org/content/repositories/orgapachenifi-1129/
> >*
> >>
> >> The Git tag is nifi-minifi-0.5.0-RC1
> >> The Git commit ID is f5c15eb6e501bce02e90c48b506a997dbda14746
> >> *
> >> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> f5c15eb6e501bce02e90c48b506a997dbda14746
> >> <
> >> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=
> f5c15eb6e501bce02e90c48b506a997dbda14746
> >> >*
> >>
> >> *
> >> https://github.com/apache/nifi-minifi/commit/
> f5c15eb6e501bce02e90c48b506a997dbda14746
> >> <
> >> https://github.com/apache/nifi-minifi/commit/
> f5c15eb6e501bce02e90c48b506a997dbda14746
> >> >*
> >> Checksums of minifi-0.5.0-source-release.zip:
> >> SHA1: da83318f2a606345d6b33aa4f89c9c2689dcf390
> >> SHA256: 8b47d7085ed31b2c2e412375caafb80d988afeb2b0d65459b4a9eb49d059
> 42b7
> >>
> >> Release artifacts are signed with the following key:
> >> https://people.apache.org/keys/committer/jeremydyer.asc
> >>
> >> KEYS file available here:
> >> https://dist.apache.org/repos/dist/release/nifi/KEYS
> >>
> >> 16 issues were closed/resolved for this release:
> >> *
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12319921=12342658
> >> <
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12319921=12342658
> >> >*
> >>
> >> Release note highlights can be found here:
> >> https://cwiki.apache.org/confluence/display/MINIFI/
> >> Release+Notes#ReleaseNotes-Version0.5.0
> >>
> >> The vote will be open until 5:00PM EDT, 29 June 2018.
> >>
> >> Please download the release candidate and evaluate the necessary items
> >> including checking hashes, signatures, build
> >> from source, and test.  Then please vote:
> >>
> >> [ ] +1 Release this package as minifi-0.4.0
> >> [ ] +0 no opinion
> >> [ ] -1 Do not release this package because...
> >>
> >> Thanks!
> >>
> >
>

[VOTE] Release Apache NiFi MiNiFi 0.5.0

[Jeremy Dyer]

Hello,

I am pleased to call this vote for the source release of Apache NiFi MiNiFi
minifi-0.5.0.

The source zip, including signatures, digests, etc. can be found at:
*https://repository.apache.org/content/repositories/orgapachenifi-1129/
*

The Git tag is nifi-minifi-0.5.0-RC1
The Git commit ID is f5c15eb6e501bce02e90c48b506a997dbda14746
*https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=commit;h=f5c15eb6e501bce02e90c48b506a997dbda14746
*

*https://github.com/apache/nifi-minifi/commit/f5c15eb6e501bce02e90c48b506a997dbda14746
*
Checksums of minifi-0.5.0-source-release.zip:
SHA1: da83318f2a606345d6b33aa4f89c9c2689dcf390
SHA256: 8b47d7085ed31b2c2e412375caafb80d988afeb2b0d65459b4a9eb49d05942b7

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/jeremydyer.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

16 issues were closed/resolved for this release:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319921=12342658
*

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/MINIFI/
Release+Notes#ReleaseNotes-Version0.5.0

The vote will be open until 5:00PM EDT, 29 June 2018.

Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build
from source, and test.  Then please vote:

[ ] +1 Release this package as minifi-0.4.0
[ ] +0 no opinion
[ ] -1 Do not release this package because...

Thanks!

Re: [DISCUSS] Release Apache NiFi MiNiFi 0.5.0

[Jeremy Dyer]

Ok sure thing I will review those now. I will let you know if I find
anything. If not I'll merge them into master and kick off the release
process.

Thanks,
Jeremy Dyer

On Tue, Jun 26, 2018 at 10:35 AM, Aldrin Piri  wrote:

> Yeah, I believe we are down to just two issues listed here to be reviewed:
> https://issues.apache.org/jira/browse/MINIFI-459?jql=
> project%20%3D%20MINIFI%20AND%20status%20in%20(Open%2C%20%
> 22In%20Progress%22%2C%20Reopened%2C%20%22Patch%20Available%22)%20AND%
> 20fixVersion%20%3D%200.5.0
>
> Otherwise, it looks like the pending items have been taken care of and we
> can move forward.
>
> Thanks for taking on the RM duties!
>
> On Mon, Jun 25, 2018 at 10:21 PM Jeremy Dyer  wrote:
>
> > Aldrin - Yep I'm happy to play the role of RM for this release. Now that
> > NiFi 1.7.0 has been released seems like the only remaining tasks are to
> > update the dependencies. Let me know if you want any help with that as
> well.
> >
> > Thanks,
> > Jeremy Dyer
> >
> > Thanks - Jeremy Dyer
> > 
> > From: Kevin Doran 
> > Sent: Sunday, June 24, 2018 11:04:26 PM
> > To: dev@nifi.apache.org; dev@nifi.apache.org
> > Subject: Re: [DISCUSS] Release Apache NiFi MiNiFi 0.5.0
> >
> >
> >
> >
> >
> >
> >
> >
> > Sounds good to me. Thanks, Aldrin.
> >
> >
> >
> > Get Outlook for iOS
> >
> >
> >
> >
> >
> > On Sun, Jun 24, 2018 at 3:04 PM -0400, "Andy LoPresto" <
> > alopresto.apa...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > +1, excited to get the new stuff into MiNiFi.
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On Jun 22, 2018, at 19:03, Aldrin Piri  wrote:
> > >
> > > Hello folks,
> > >
> > > With the NiFi vote under way, I was thinking it was an appropriate time
> > to
> > > start discussion around the release of 0.5.0.  There have been some
> > > important fixes as well as some initial support for integration with
> > > Registry.  I think we should get MiNiFi upgraded to 1.7.0 dependencies
> > when
> > > that release successfully completes and start the release process.
> > >
> > > It seems Jeremy already made a ticket to do so.  Jeremy, are you
> > > volunteering to RM?  If not, I am happy to do so if no one else has any
> > > interest.
> > >
> > > Thanks!
> > > Aldrin
> >
> >
> >
> >
> >
> >
>

Re: [DISCUSS] Release Apache NiFi MiNiFi 0.5.0

[Jeremy Dyer]

Aldrin - Yep I'm happy to play the role of RM for this release. Now that NiFi 
1.7.0 has been released seems like the only remaining tasks are to update the 
dependencies. Let me know if you want any help with that as well.

Thanks,
Jeremy Dyer

Thanks - Jeremy Dyer

From: Kevin Doran 
Sent: Sunday, June 24, 2018 11:04:26 PM
To: dev@nifi.apache.org; dev@nifi.apache.org
Subject: Re: [DISCUSS] Release Apache NiFi MiNiFi 0.5.0








Sounds good to me. Thanks, Aldrin.



Get Outlook for iOS





On Sun, Jun 24, 2018 at 3:04 PM -0400, "Andy LoPresto" 
 wrote:










+1, excited to get the new stuff into MiNiFi.

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jun 22, 2018, at 19:03, Aldrin Piri  wrote:
>
> Hello folks,
>
> With the NiFi vote under way, I was thinking it was an appropriate time to
> start discussion around the release of 0.5.0.  There have been some
> important fixes as well as some initial support for integration with
> Registry.  I think we should get MiNiFi upgraded to 1.7.0 dependencies when
> that release successfully completes and start the release process.
>
> It seems Jeremy already made a ticket to do so.  Jeremy, are you
> volunteering to RM?  If not, I am happy to do so if no one else has any
> interest.
>
> Thanks!
> Aldrin

Re: nifi not running (installation problem) - brew

[Jeremy Dyer]

To Kevin's point Java 10 or even 9 for that matter is not yet supported. If
you don't want to use mess with your existing environment setup we do offer
a docker image[1] that you can run if interested.

[1] - https://hub.docker.com/r/apache/nifi/

Thanks,
Jeremy Dyer

On Thu, Jun 7, 2018 at 9:41 AM, Kevin Doran  wrote:

> The version of NiFi you are using (1.6.0) requires Java 8 (jre or jdk 1.8).
>
> Regards,
> Kevin
>
> On 6/7/18, 09:38, "kirilzilla"  wrote:
>
> Hi, im writing my bachelor thesis and would like to use apache nifi.
> im using macOS 10.13.5 right now and installed nifi over brew packet
> manager
> "brew install nifi".
>
> i can't access the user interface, because nifi doesn't seem to start.
> http://localhost:8080/nifi
>
> if i run "nifi start"
> this is the output:
>
> nifi start
>
> Java home: /Library/Java/JavaVirtualMachines/jdk-10.0.
> 1.jdk/Contents/Home
> NiFi home: /usr/local/Cellar/nifi/1.6.0/libexec
>
> Bootstrap Config File:
> /usr/local/Cellar/nifi/1.6.0/libexec/conf/bootstrap.conf
>
> then, when running "nifi status"
> nifi status
>
> Java home: /Library/Java/JavaVirtualMachines/jdk-10.0.
> 1.jdk/Contents/Home
> NiFi home: /usr/local/Cellar/nifi/1.6.0/libexec
>
> Bootstrap Config File:
> /usr/local/Cellar/nifi/1.6.0/libexec/conf/bootstrap.conf
>
> *2018-06-07 15:35:08,955 INFO [main] org.apache.nifi.bootstrap.Command
> Apache NiFi is not responding to Ping requests. The process may have
> died or
> may be hung*
>
>
> my java versions:
> java --version
> java 10.0.1 2018-04-17
> Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)
>
>
>
>
> --
> Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/
>
>
>
>

Re: Question on Docker module

[Jeremy Dyer]

Sivaprasanna - They are very similar but different. Exists to primarily
assist with speeding up a developers dev cycle. Its purpose is to allow you
to make source code changes to NiFi, build with maven (including docker
image), and then run the container with your latest changes. So in a sense
you can think of the docker maven module as providing you with the latest
from master. The dockerhub module on the other hand is used to build an
image for a stable Apache validated release. The current dockerhub build
will pull down Apache NiFi 1.6 from the Apache mirrors.

TLDR: In cases outside of development you should use the dockerhub one.

Thanks,
Jeremy Dyer

On Thu, Jun 7, 2018 at 9:09 AM, Sivaprasanna 
wrote:

> Team,
>
> In the project's nifi-docker
> <https://github.com/apache/nifi/tree/master/nifi-docker> module, we have
> two things: dockerhub and dockermaven. Are they one and the same or they
> are there for different purposes? I have to warn you I don't know much
> about 'dockerfile-maven-plugin' so some light on this might help me
> understand the differences (if at all).
>
> Thanks,
> Sivaprasanna
>

[ANNOUNCE] Apache NiFi MiNiFi C++ 0.5.0 release

[Jeremy Dyer]

Hello

The Apache NiFi team would like to announce the release of Apache NiFi
MiNiFi C++ 0.5.0.

MiNiFi—a subproject of Apache NiFi—is 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.

Specific goals for the initial thrust of the MiNiFi effort comprise:

· 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

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=12342659

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.5.0

Thank you
The Apache NiFi team

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

[Jeremy Dyer]

Thanks for the feedback Koji. I removed the references to MD5 from the
MiNiFi release wiki[1] so next time we will avoid supplying the MD5
checksum.

[1] -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=70254849

On Mon, Jun 4, 2018 at 11:28 AM, Koji Kawamura 
wrote:

> +1 (binding)
>
> - Verified hashes
> - Build and unit tests succeeded
> - Run simple flows to send data from MiNiFi CPP to NiFi
> - on Mac OS 10.13.4
>
> I have a feedback on the release procedure.
> Apache Release distribution policy has following:
> "SHOULD NOT supply a MD5 checksum file (because MD5 is too broken)."
> http://www.apache.org/dev/release-distribution#sigs-and-sums
> NiFi release stopped supplying MD5 checksum since 1.6.0 and MiNiFi
> should do that.
>
> Appreciate all the improvements and bug fixes for this release. Thanks
> to Jeremy to take the release manager role!
>
> Thanks,
> Koji
>
> On Mon, Jun 4, 2018 at 10:10 AM, Kevin Doran  wrote:
> > +1 (non-binding)
> >
> > I followed the steps in the helper guide and was able to verify the
> agent works as expected with a couple test flows that send data to NiFi
> over s2s. Most of my RC verification was done with the agent on Mac OS
> 10.12. A full build with tests passed on Ubuntu 16.04 for me.
> >
> > One very minor issue I ran into was a faulty Y/N prompt in bootstrap.sh
> when selecting "N" to bail at the cmake confirmation. It doesn't really do
> any harm as you can easily blow away the build dir and start over, and is
> an easy fix. I filed a JIRA [1] and opened a PR that corrects it [2]. And
> overall, the bootstrap stuff really makes this a lot easier to build and
> deploy on new platforms, so I'm really enjoying using that.
> >
> > Great work everyone who contributed to the agent since the last release.
> This is a nice step forward! And thanks Jeremy for managing the release!
> >
> > [1] https://issues.apache.org/jira/browse/MINIFICPP-523
> > [2] https://github.com/apache/nifi-minifi-cpp/pull/351
> >
> > On 5/31/18, 20:39, "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
> > <https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-
> cpp.git;a=commit;h=5f3b3973e37def4d8ed2753837986d121fd58322>*
> > * *https://github.com/apache/nifi-minifi-cpp/commit/
> 5f3b3973e37def4d8ed2753837986d121fd58322
> > <https://github.com/apache/nifi-minifi-cpp/commit/
> 5f3b3973e37def4d8ed2753837986d121fd58322>*
> >
> > Checksums of nifi-minifi-cpp-0.5.0-source.tar.gz:
> > MD5: 9ec230b9ac3004981000276015860c52
> > SHA1: a9e3fe34ed25f9f1a840cd318845bcdb6fb622f1
> > SHA256: 78b5bbd65d1e3484efafc02a882f99063e06b88e1694daff6c24aaa30660
> 37dc
> >
> > 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
> > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12321520=12342659>*
> >
> > Release note highlights can be found here:
> > *https://cwiki.apache.org/confluence/display/MINIFI/
> Release+Notes#ReleaseNotes-Versioncpp-0.5.0
> > <https://cwiki.apache.org/confluence/display/MINIFI/
> 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!
> >
> >
> >
>

[RESULT][VOTE] Release Apache NiFi MiNiFi C++ 0.5.0

[Jeremy Dyer]

Apache NiFi Community,

I am pleased to announce that the 0.5.0 release of Apache NiFi MiNiFi C++
passes with
 4 +1 (binding) votes
 1 +1 (non-binding) votes
 0 0 votes
 0 -1 (binding) votes
 0 -1 (non-binding) votes

Thanks to all who helped make this release possible.

Here is the PMC vote thread:
https://lists.apache.org/thread.html/14e6009697fb6f3faf3b51cfb490705c308b121b1e0c01f91121b76d@%3Cdev.nifi.apache.org%3E

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

[Jeremy Dyer]

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-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
> >> > <https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-
> >> cpp.git;a=commit;h=5f3b3973e37def4d8ed2753837986d121fd58322>*
> >> > * *https://github.com/apache/nifi-minifi-cpp/commit/
> >> 5f3b3973e37def4d8ed2753837986d121fd58322
> >> > <https://github.com/apache/nifi-minifi-cpp/commit/
> >> 5f3b3973e37def4d8ed2753837986d121fd58322>*
> >> >
> >> > Checksums of nifi-minifi-cpp-0.5.0-source.tar.gz:
> >> > MD5: 9ec230b9ac3004981000276015860c52
> >> > SHA1: a9e3fe34ed25f9f1a840cd318845bcdb6fb62

Apache NiFi MiNiFi C++ 0.5.0 RC1 Release Helper Guide

[Jeremy Dyer]

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.5.0 source release artifacts for review:

wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz
wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.asc
wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.md5
wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.sha1
wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.5.0/nifi-minifi-cpp-0.5.0-source.tar.gz.sha256

# Verify the signature
gpg --verify nifi-minifi-cpp-0.5.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.5.0-source.tar.gz
sha1sum nifi-minifi-cpp-0.5.0-source.tar.gz
sha256sum nifi-minifi-cpp-0.5.0-source.tar.gz

# tar -xzvf nifi-minifi-cpp-0.5.0-source.tar.gz

# Verify the build works including release audit tool (RAT) checks
cd nifi-minifi-cpp-0.5.0-source
./bootstrap.sh && cd build && 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 binary as found in nifi-assembly/target

# Make sure the README, NOTICE, and LICENSE are present and correct

# Run the resulting convenience binary and make sure it works as expected

# Send a response to the vote thread indicating a +1, 0, -1 based on your
findings.

Thank you for your time and effort to validate the release!

[VOTE] Release Apache NiFi MiNiFi C++ 0.5.0

[Jeremy Dyer]

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
*
* 
*https://github.com/apache/nifi-minifi-cpp/commit/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
*

Release note highlights can be found here:
*https://cwiki.apache.org/confluence/display/MINIFI/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: [DISCUSS] Apache NiFi MiNiFi C++ 0.5.0

[Jeremy Dyer]

No problem. Let me know when you get that PR merged in and I’ll 
kick off the release process



Thanks - Jeremy Dyer





On Wed, May 23, 2018 at 1:20 PM -0400, "Marc" <phroc...@apache.org> wrote:










Jeremy,
  Thanks for stepping up!

Aldrin,
  I moved one ticket over that should be in 0.5.0 for which a PR
exists. Aside from that we should be good to go when that is merged.

On Wed, May 23, 2018 at 11:15 AM, Andy Christianson
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>> Sounds great and I think we've gotten some important changes into the
>> codebase from when this first started.  Do we have all the
>> appropriate/needed issues tagged for this release?
>
> I support this release.
>
> For this release, I would like to bring special attention to MINIFICPP-281,
> which has been marked "RESOLVED." In order for that to work, whoever builds 
> the
> .tar.gz should build the binary with all static linking options enabled, which
> will minimize dependencies on libraries which may only be on the packager's
> system, while maximizing portability of the tarball release.
>
> Regards,
>
> Andy I.C.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJbBYVvAAoJEG1+mBKNMpIDH9sH/jnbw3hqxBVSZcZwimy2bmEN
> P64YR3k6Q+OT2pCIp3e88aAHLLy3KUGlZiltp7viiAiNIcHFAmEkbUfpsDEZB6On
> EyZJMV1NhEx3zDgapfhY3BUcarOgOjL77ZcVCuw3OU0LAkZFrXxG7Ok9YTY2smP8
> ve4Geck/O8aCtGL5hnNHecJGrm7KsVKbpUeutvwMMTLMNOPwv7ukxLp0o6QufR54
> cA0nIPJmLrbuCOWWJzSAzLXHu3Wzox9UQ9htNOHgqmzYCAEpMDZrHGE5xJs9K3Iy
> tLVRebJdQfvH+woKWzmwsqrgf3mSoY2iohza/46Tu3+OvETvVtS44RnFz3paKek=
> =WN7S
> -END PGP SIGNATURE-
>
> Sent from ProtonMail, Swiss-based encrypted email.

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.5.0

[Jeremy Dyer]

I’m happy to handle RM duties



Thanks - Jeremy Dyer





On Tue, May 22, 2018 at 10:25 AM -0400, "Marc" <phroc...@apache.org> wrote:










Reviving this thread -- Sorry for the delay. I will start the release
process with the completion of [1], likely in the next few days or
early next week. I will take RM duties unless someone else would like
to take that opportunity.

[1] https://issues.apache.org/jira/browse/MINIFICPP-457

Thanks,
Marc

On Sun, Feb 18, 2018 at 9:17 AM, Joe Witt  wrote:
> sounds good!
>
> On Feb 18, 2018 9:15 AM, "Kevin Doran"  wrote:
>
>> Hi Marc,
>>
>> Thanks for kicking off this discuss thread. I agree we should start
>> planning the next release to get these new and improved capabilities into a
>> stable version for users.
>>
>> Thanks!
>> Kevin
>>
>> On 2/14/18, 13:42, "Marc"  wrote:
>>
>> Hello Everyone,
>>   I wanted to discuss releasing 0.5.0 in the coming weeks. We have some
>> really useful features and bug fixes in place or nearly up for review.
>> I am
>> proposing that we release Apache NiFi MiNiFi C++ 0.5.0 when these
>> activities are complete.
>>
>>We've had some very useful processors added (UpdateAttribute added
>> RouteOnAttribute coming ) , MQTT security, support for SUSE/SLES, C2
>> updates, and various bug fixes. If everyone is favorable to begin the
>> release process I am happy to act as RM if no one else is interested.
>>Thanks for your consideration,
>>Marc
>>
>>
>>
>>

Re: [DISCUSS] Change Apache NiFi Fluid Design System naming

[Jeremy Dyer]

Makes complete sense to me +1

On Thu, May 17, 2018 at 10:00 AM, Matt Burgess  wrote:

> Makes sense to me, I'm a +1 as well.
>
> On Wed, May 16, 2018 at 4:52 PM, Scott Aslan 
> wrote:
> > Good timing as we're close to ready for a first nifi-fds release.
> >
> > I would definitely favor us keeping the 'nifi-fds' naming as that means I
> > dont have to change a bunch of code so Apache NiFi Flow Design System
> does
> > that just fine. I will take care of updating the readme and other areas
> we
> > need to change but we can keep the repo as-is with this.
> >
> > The descriptive name is better, generic, and consistent with some of the
> > discuss thread feedback a while back anyway.
> >
> > I'll wait to kick off the release for the outcome of this discussion and
> > vote.
> >
> > I'm +1 on this.
> >
> > Thanks
> >
> > On Wed, May 16, 2018 at 2:46 PM, Rob Moran  wrote:
> >
> >> I think it's important to highlight that for nifi-fds the 'f' part of
> the
> >> name was for 'fluid.' This is part of a FLUID product design system [1]
> to
> >> which I also contribute, that at the time was an internal concept, but
> is
> >> now being described in a public manner. However, nifi-fds is partially
> >> inspired by FLUID concepts as well as others. Specifically, Material
> Design
> >> [2] and Teradata's Covalent UI Platform [3].
> >>
> >> We should change the name to reflect that what we're aiming for is a
> set of
> >> reusable UI components that the NiFi ecosystem can leverage. The UI
> >> components are inspired by these design systems, and will possibly be
> >> influenced by others as it evolves.
> >>
> >> Since we've already established the FDS naming scheme, I propose a
> simple
> >> path would be to call it the Apache NiFi *Flow* Design System rather
> than a
> >> unique/standalone term. This way the nifi-fds repo will not require a
> >> change. We can just update the descriptions.
> >>
> >> I assume we should vote on this if others agree?
> >>
> >> [1] http://productdesign.hortonworks.com/
> >> [2] https://material.io/design/
> >> [3] https://teradata.github.io/covalent/#/
> >>
>

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

[Jeremy Dyer]

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

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

[Jeremy Dyer]

+1 non binding. Ran through release guide with no issues and ran several test 
workflows from personal projects

- Jeremy Dyer

> On Jan 9, 2018, at 8:11 PM, Andy LoPresto <alopre...@apache.org> wrote:
> 
> +1, binding
> 
> I performed the following verifications:
> 
> * verified the GPG key signature
> * verified the MD5/SHA1/SHA256 checksums
> * verified the git commit ID
> * verified the presence of LICENSE, NOTICE, and README
> * verified the Maven build was successful, including all unit tests, RAT 
> check, and code style guidelines
> * verified the application started successfully
> * verified the new behavior for host header handling was present
> * verified the application integrates successfully with the Apache NiFi 
> Registry
> * verified the CountText processor works as anticipated
> * verified the flow versioning functionality by making local changes, 
> committing, and restoring prior versions of the flow
> 
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
>> On Jan 9, 2018, at 9:13 AM, Mark Payne <marka...@hotmail.com> wrote:
>> 
>> +1 (binding) - Release this package as nifi-1.5.0
>> 
>> Was able to successfully build with contrib-check and grpc profile. Verified 
>> MD5 sum.
>> Started up, added a Flow Registry Client pointing to an existing Flow 
>> Registry and was
>> able to immediately import a flow and start it running. This flow also 
>> verified the fix for
>> NIFI-4749 made it into the build yesterday.
>> 
>> Thanks for taking on the RM duties this time, Joe! And a big thank you and 
>> congrats
>> to all of the members of the community that contributed to this release - 
>> code, JIRA's,
>> docs, and support!
>> 
>> Thanks
>> -Mark
>> 
>> 
>>> On Jan 9, 2018, at 5:19 AM, Joe Witt <joew...@apache.org> 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: 40b155c4911414907835f2eb0d5a4da798935f27f1e5134218d904fe6c942d13
>>> 
>>> 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...
>> 
> 

Re: [ANNOUNCE] New Apache NiFi Committer Kevin Doran

[Jeremy Dyer]

Awesome news! Congratulations Kevin and glad to have you on board!

On Wed, Jan 3, 2018 at 12:07 PM, Gerdan Rezende dos Santos  wrote:

> great job and congrats!
>
> --
> *Gerdan Rezende dos Santos*∴
> Hortonworks, PostgreSQL & EnterpriseDB Specialist, Support, Training &
> Services
> +55 (61) 996 451 525
>
> On Wed, Jan 3, 2018 at 2:21 PM, Marc  wrote:
>
> > Congrats Kevin! Agreed, well deserved!
> >
> > On Jan 3, 2018 9:48 AM, "Scott Aslan"  wrote:
> >
> > Congrats Kevin! Well deserved!
> >
> > On Wed, Jan 3, 2018 at 9:45 AM, Matt Burgess 
> wrote:
> >
> > > Congrats and welcome aboard Kevin!
> > >
> > > On Wed, Jan 3, 2018 at 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!
> > >
> >
>

Re: [ANNOUNCE] New NiFi PMC member Marc Parisi

[Jeremy Dyer]

Congrats Marc! Lots of good work I have seen from you and appreciate all you 
have given the community!

- Jeremy Dyer

> On Dec 14, 2017, at 8:29 PM, Scott Aslan <scottyas...@gmail.com> wrote:
> 
> Congrats!
> 
>> On Thu, Dec 14, 2017 at 6:50 PM, Matt Burgess <mattyb...@apache.org> wrote:
>> 
>> Congratulations Marc with a C :) Welcome aboard, looking forward to
>> more kick-arse contributions!
>> 
>>> On Thu, Dec 14, 2017 at 6:47 PM, Tony Kurc <tk...@apache.org> wrote:
>>> NiFi community,
>>> On behalf of the Apache NiFi PMC, I am pleased to announce that Marc
>> Parisi
>>> has accepted the PMC's invitation to join the Apache NiFi PMC.  We
>> greatly
>>> appreciate all of Marc's hard work and generous contributions to the
>>> project. We look forward to continued involvement in the project.
>>> 
>>> Marc is a major contributor to MiNiFi CPP; in addition to his code and
>>> review contributions, he recently release managed the 0.3.0 release. He's
>>> super friendly, active across the NiFi project, and can lift a small car.
>>> 
>>> Congratulations and welcome, Marc!
>>> 
>>> Tony
>> 

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

[Jeremy Dyer]

+1 built, tested, can sample flow, and validated existance of LICENSE and
README in resulting binary.

On Wed, Nov 29, 2017 at 1:09 PM, Aldrin Piri  wrote:

> +1, binding
>
> Built, tested, and created Docker container on OS X 10.12, Centos 7.3,
> Ubuntu 16.04.2
>
> Ran a few flows and verified expected functionality on each system.
>
> On Tue, Nov 28, 2017 at 11:08 AM, Andy Christianson <
> aichr...@protonmail.com
> > wrote:
>
> > +1
> >
> > Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> > email.
> >
> > >  Original Message 
> > > Subject: [VOTE] Release Apache NiFi MiNiFI C++ 0.3.0 (RC2)
> > > Local Time: November 27, 2017 11:59 AM
> > > UTC Time: November 27, 2017 4:59 PM
> > > From: phroc...@apache.org
> > > To: dev@nifi.apache.org
> > >
> > > 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.gi
> > t;a=commit;h=0e4ce79b78cbc9c89189eabb8042749a873d9723
> > > *
> > > https://github.com/apache/nifi-minifi-cpp/commit/0e4ce79b78c
> > bc9c89189eabb8042749a873d9723
> > >
> > > 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?proje
> > ctId=12321520=12341640
> > >
> > > Release note highlights can be found here:
> > > https://cwiki.apache.org/confluence/display/MINIFI/Release+N
> > otes#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)

[Jeremy Dyer]

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 <phroc...@apache.org> 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 <jdy...@gmail.com> 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 there is an update of
>> RocksDB where this would work however. What do you think?
>> 
>>> On Tue, Nov 21, 2017 at 3:06 PM, Marc <phroc...@apache.org> wrote:
>>> 
>>> Hello Apache NiFi Community,
>>> 
>>> I am pleased to be calling 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-RC1
>>> The Git commit hash is d3852a73beaafa78a789d975f6d3a595b7761d41
>>> *
>>> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.
>> git;a=commit;h=
>>> d3852a73beaafa78a789d975f6d3a595b7761d41
>>> *
>>> https://github.com/apache/nifi-minifi-cpp/commit/
>>> d3852a73beaafa78a789d975f6d3a595b7761d41
>>> 
>>> Checksums of nifi-minifi-cpp-0.3.0-source.tar.gz:
>>> MD5: 8bcc8987e8322e1be0ddc631adc4f9bd
>>> SHA1: 811cc8c54572f25121b64b123a8fca176e81509b
>>> SHA256: f87815c31b5b15a30d2261800a89d9eab678d5ecc485d53f83c035d6ddb31b8a
>>> 
>>> 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
>>> 
>>> 59 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
>>> 
>>> Since Thursday is a major US Holiday, the vote will be open for 96 hours
>>> and will close on 25 Nov at 3PM 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-rc1-close
>>> 
>> 

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

[Jeremy Dyer]

-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 there is an update of
RocksDB where this would work however. What do you think?

On Tue, Nov 21, 2017 at 3:06 PM, Marc  wrote:

> Hello Apache NiFi Community,
>
> I am pleased to be calling 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-RC1
> The Git commit hash is d3852a73beaafa78a789d975f6d3a595b7761d41
> *
> https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-cpp.git;a=commit;h=
> d3852a73beaafa78a789d975f6d3a595b7761d41
> *
> https://github.com/apache/nifi-minifi-cpp/commit/
> d3852a73beaafa78a789d975f6d3a595b7761d41
>
> Checksums of nifi-minifi-cpp-0.3.0-source.tar.gz:
> MD5: 8bcc8987e8322e1be0ddc631adc4f9bd
> SHA1: 811cc8c54572f25121b64b123a8fca176e81509b
> SHA256: f87815c31b5b15a30d2261800a89d9eab678d5ecc485d53f83c035d6ddb31b8a
>
> 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
>
> 59 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
>
> Since Thursday is a major US Holiday, the vote will be open for 96 hours
> and will close on 25 Nov at 3PM 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-rc1-close
>

Re: [ANNOUNCE] New Apache NiFi Committer Andy Christianson

[Jeremy Dyer]

Good to have you Andy!

Sent from my iPhone

> On Nov 14, 2017, at 11:06 AM, Scott Aslan  wrote:
> 
> Congrats
> 
>> On Tue, Nov 14, 2017 at 8:11 AM, Marc  wrote:
>> 
>> Congrats
>> 
>> On Nov 14, 2017 1:29 AM, "Pierre Villard" 
>> wrote:
>> 
>> Congrats!
>> 
>> Le 14 nov. 2017 04:16, "Jeff"  a écrit :
>> 
>>> Congrats, Andy!
>>> 
>>> On Mon, Nov 13, 2017 at 9:44 PM Kevin Doran 
>>> wrote:
>>> 
 Congrats, Andy! Thanks for all the hard work on MiNiFi CPP!
 
 On 11/13/17, 19:39, "Tony Kurc"  wrote:
 
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
 
 
 
 
>>> 
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Mike Hogue

[Jeremy Dyer]

Mike glad to have you and looking forward to working with you on things in
the future!

On Thu, Nov 9, 2017 at 7:14 PM, Tony Kurc  wrote:

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

Re: [ANNOUNCE] New Apache NiFi Committer Peter Wicks

[Jeremy Dyer]

Welcome Peter excited to have you on board!

On Thu, Nov 9, 2017 at 7:14 PM, Tony Kurc  wrote:

> 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: [DISCUSS] Apache NiFi MiNiFi C++ 0.3.0

[Jeremy Dyer]

I agree it’s time. Marc beat me to RM duties this time but happy to offer up 
doing it next time

- Jeremy

> On Nov 3, 2017, at 11:13 AM, Kevin Doran  wrote:
> 
> I agree. There's been a lot of great commits to master recently and it would 
> be great to have them in a new release version.
> 
> Thanks!
> Kevin
> 
> On 11/1/17, 15:05, "Aldrin Piri"  wrote:
> 
>Hey folks,
> 
>We've had a fair amount of work and enhancements to the framework and
>extensions and seemed like a logical place to offer up a new release.  Both
>Execute Script and HTTP Site to Site seem to be nearing their merge into
>master.  With a quick look through other open JIRAs it appears as some of
>the newer tickets starting progress might be extended efforts.
> 
>Let me know if anyone has any thoughts or comments.  Otherwise, we can try
>to generate an RC and vote in the next week.  I am happy to act as RM if no
>one else is interested in doing so (likely have some docs I need to update
>to capture the process a bit better).
> 
> 
>--Aldrin
> 
> 
> 

Re: [ANNOUNCE] New Apache NiFi Committer Marc Parisi

[Jeremy Dyer]

Congratulations Marc! Have really enjoyed working and learning from you on the 
C++ side of the house. Look forward to your further work!

Sent from my iPhone

> On May 31, 2017, at 9:37 PM, Tony Kurc  wrote:
> 
> 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

Re: [DISCUSS] NiFi MiNiFi C++ 0.2.0 Release

[Jeremy Dyer]

Thanks Aldrin. I'm working on wrapping up that final issue now

On Wed, May 3, 2017 at 10:55 AM, Aldrin Piri  wrote:

> Looks like we have one last item scheduled [1] for this release version
> with review under way since the last message.  We've also uncovered and
> remedied a few build and test issues during that same time period which
> will make for nice additions.  Upon conclusion of the review process for
> the remaining item, I will move forward conducting the release.
>
> Thanks!
>
> --aldrin
>
> [1]
> https://issues.apache.org/jira/browse/MINIFI-286?jql=
> fixVersion%20%3D%20cpp-0.2.0%20AND%20project%20%3D%
> 20MINIFI%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20priority%20DESC
>
> On Thu, Apr 13, 2017 at 10:19 AM, Aldrin Piri 
> wrote:
>
> > Hey folks,
> >
> > We've had a good bit of progress on MiNiFi C++ and think we have reached
> a
> > point where it makes sense to capture some of the good strides that have
> > been made so far and start another release.
> >
> > There are currently three issues open [1]. Two of which have patches,
> near
> > completion, and the third which may be a candidate for an 0.3.0 target.
> >
> > I would be happy to carry out release duties unless there are other folks
> > that feel so inclined.  I have also created a JIRA [2] to aid in tracking
> > any additional concerns or dependencies for the process.
> >
> > Thanks for your consideration!
> >
> > --aldrin
> >
> > [1] https://issues.apache.org/jira/browse/MINIFI-227?jql=
> > fixVersion%20%3D%20cpp-0.2.0%20AND%20project%20%3D%
> > 20MINIFI%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20priority%20DESC
> > [2] https://issues.apache.org/jira/browse/MINIFI-267
> >
>

Re: Revisiting MINIFI-175; minifi-cpp Alpine Dockerfile

[Jeremy Dyer]

I'm all about smaller and alpine. To Aldrin's point I think we just wanted 
something out there at first and fully expected to optimize later

Sent from my iPhone

> On Apr 26, 2017, at 11:29 AM, Bryan Rosander  wrote:
> 
> I'm definitely in favor of smaller images, especially given the nature of
> the subproject.  I think the MiNiFi Java image may be able to benefit from
> Alpine as well.
> 
> Thanks,
> Bryan
> 
>> On Wed, Apr 26, 2017 at 11:09 AM, Aldrin Piri  wrote:
>> 
>> Don't think there would be any objections to going smaller with Alpine and
>> certainly makes a lot of sense, but I believe initial efforts were
>> problematic and there was a general desire to get a foundation going.  The
>> biggest issue was needing to navigate cross compilation of a given host to
>> the Alpine format which was something our processes are not quite up to at
>> this juncture.  The integrated dev setup in the image avoided having to
>> tackle this and allowed building of the image on any system where Docker
>> could run whether natively or via one of the Docker for $OS setups.
>> 
>> Hadn't actually been aware of the multi-stage docker builds before this
>> thread, but certainly seems like a great application after looking through
>> the associated PRs and docs and could be a more immediate win for the
>> particular case above.
>> 
>> We could and should certainly strive to make components pluggable, in this
>> case logging, to support such cases where things may be problematic given a
>> target environment.  I don't think I'd be in favor of removing spdlog at
>> this point but could apply similar approaches used elsewhere in the
>> codebase to give us a little more configurability to use an alternate
>> implementation.
>> 
>> Would be in favor of opening up an issue to optimize our Docker build and
>> certainly target Alpine with some of the new build magic.  By the time we
>> have it implemented, the multi-stage builds should likely be sufficiently
>> available.
>> 
>> On Wed, Apr 26, 2017 at 10:19 AM, Andrew Christianson <
>> andrew.christian...@nextcentury.com> wrote:
>> 
>>> Have we considered porting the current Dockerfile from Ubuntu to Alpine?
>>> The ubuntu image, especially with all the build-time deps left in the
>> final
>>> image, is quite bloated. This runs against the design intent of minimal
>>> footprint in minifi-cpp. Further, the new multi-stage Docker builds would
>>> allow us to isolate the build environment in its own stage and allow only
>>> runtime deps to exist in the final image. Overall it would be a much
>>> smaller image.
>>> 
>>> Reviewing the JIRA activity for MINIFI-175, it seems the decision to not
>>> use alpine was originally due to the desire to encapsulate the build of
>>> minifi inside the build of the docker image, which for some reason wasn't
>>> compatible with using alpine. On initial testing, it seems alpine's musl
>>> libc has issues with spdlog. Since it may involve some effort and
>> decision
>>> making with regard to which dependencies are used, this is a decision
>>> probably best made by the community.
>>> 
>>> Thoughts?
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Bin Qiu

[Jeremy Dyer]

Congrats Bin! Also thank you for the cpp reporting task commit today awesome 
stuff! Will be very beneficial in helping the community achieve a more unified 
platform among the NiFi suite

Sent from my iPhone

> On Apr 4, 2017, at 4:22 PM, Joe Witt  wrote:
> 
> Big congrats Bin!  Extremely appreciative of all the work you've done
> helping MiNiFi CPP come along.
> 
>> On Tue, Apr 4, 2017 at 4:17 PM, Tony Kurc  wrote:
>> Apache NiFi community,
>> 
>> 
>> On behalf of the Apache NiFI PMC, I am very pleased to announce that Bin
>> Qiu has accepted the PMC's invitation to become a committer on the Apache
>> NiFi project. We greatly appreciate all of Bin’s hard work and generous
>> contributions and look forward to continued involvement in the project.
>> 
>> Bin has been one of the driving forces behind MiNiFi - C++, contributing a
>> massive amount in terms of code and helping with release verification and
>> always being responsive to the community.
>> 
>> 
>> Congrats, Bin!
>> 
>> 
>> - Tony

[DISCUSS] MiNiFi CPP Build Command UI

[Jeremy Dyer]

Team,

I wanted to discuss introducing a dynamic Apache NiFi MiNiFi CPP build
asset to the website. Currently building the cpp agent takes a fair amount
of system setup and insight to the project. I want to ease adoption by
introducing a webpage on the website that allows an end user to select
things like os, target architecture, build host os, build options (GPS
integration, etc), statically linked libraries or not, etc. After the user
drills down through the selection options a list of required dependencies
for their OS and cmake build command will be displayed on the page. Not
only will this ease in users building for the multiple targets but can help
us out on the dev side since we because have issues they can include this
snapshot with their error logs to help give us insight into potential
problem areas. Below is a high level list of features that I currently have
in mind.

Features:
- Dynamic selection of build targets and options
- List of system dependencies for target
- cmake command for target
- future support for actual binary downloads from this form
- output download so that file can be attached to JIRAs or emails related
to build errors for troubleshooting
- simple HTML and JSON driven functionality so no extra infrastructure will
be required from Apache infrastructure.

I would love to hear ideas from others so that I can compile them into a
JIRA and begin working towards a first draft release. This can certainly be
an iterative process but I believe the sooner we can get something out
working even if its a bare minimum implementation the more adoption we will
see with the project.

I have attached a 20 minute mock up screenshot of very roughly what I have
in mind. Certainly the actual build out will be better just wanted a high
level visual for everyone to see.

Thanks,
Jeremy Dyer

Re: Minifi receiving flowflie through Remote process

[Jeremy Dyer]

Just to clarify it will work in the c++ version just not the java version

> On Feb 23, 2017, at 9:14 AM, Bryan Rosander <brosan...@apache.org> wrote:
> 
> Hey Rafael Carlos,
> 
> Unfortunately, remote process group output ports aren't currently supported
> in MiNiFi [1].  There is currently a Jira case to support this
> functionality [2].
> 
> Thanks,
> Bryan
> 
> [1]
> https://nifi.apache.org/minifi/system-admin-guide.html#remote-process-groups
> [2] https://issues.apache.org/jira/browse/MINIFI-176
> 
>> On Thu, Feb 23, 2017 at 8:18 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
>> 
>> Hey Rafael
>> 
>> Can you please attach the error that you are seeing? It would also be
>> helpful to see your minifi YAML configuration file if there is nothing
>> sensitive in there.
>> 
>> Are you using the java or c++ minifi version?
>> 
>> Thanks
>> 
>> Sent from my iPhone
>> 
>>> On Feb 22, 2017, at 11:20 PM, Rafael Carlos Rosa <
>> rafaelcarl...@gmail.com> wrote:
>>> 
>>> Hi,
>>> Atarted using Minifi.
>>> Tried with remote Input Ports and worked like a charm.
>>> Tried with remote Output Ports  and got an error.
>>> I'm doing something wrong or we didnt have this feature yet?
>>> 
>>> Thanks,
>>> Rafael Carlos
>>> 
>>> "Impossible is just a word people use to feel better about themselves
>> when
>>> they give up..."
>>> --Somewhere on the internet--
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Jeff Storck

[Jeremy Dyer]

Congratulations Jeff! Good to have you aboard!

On Tue, Feb 21, 2017 at 2:41 PM, Aldrin Piri  wrote:

> On behalf of the Apache NiFI PMC, I am very pleased to announce that Jeff
> Storck has accepted the PMC's invitation to become a committer on the
> Apache NiFi project. We greatly appreciate all of Jeff's hard work and
> generous contributions and look forward to continued involvement in the
> project.
>
> Jeff's contributions include significant efforts toward upgrade and
> migration processes inclusive of flow layout when upgrading from 0.x to 1.x
> and the ZooKeeper migration toolkit.
>
> Congrats, Jeff!
>

Re: Namespaces in MiNiFI-cpp

[Jeremy Dyer]

Marc - I responded in https://issues.apache.org/jira/browse/MINIFI-217
directly but I think this is a good idea. The sooner we do this the less
painful it will be. I also like the additional namespaces like *io and
*processors that you lay out in the JIRA.

On Thu, Feb 16, 2017 at 7:24 AM, Marc  wrote:

> Good timezone appropriate salutation,
>
>I'd like to move the MiNiFi-CPP agent to a more controlled namespace,
> namely org::apache::nifi::minifi . In an upcoming PR I'll introduce a
> directory for I/O activities and using namespaces will help better isolate
> and encapsulate the duties of the code; however, I wanted to make sure
> everyone is okay with these namespace changes.
>
> First and foremost, the question would be: will this impact anyone?
>
>  https://issues.apache.org/jira/browse/MINIFI-217
>
> I wouldn't immediately make the change, to avoid impacting devs who are
> expecting the global namespace. I put an arbitrary estimate in the ticket
> to reflect notice being given before applying the change to the mainline.
>
>  Feel free to comment on the ticket with objections and/or timeline
> requests. This is pretty low priority, but I wanted to provide sufficient
> notice.
>
>  Best Regards,
>  Marc Parisi
>

Re: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Jeremy Dyer]

+1 non-binding. I like the separation and I see a lot of need for this in
the community.

On Fri, Feb 10, 2017 at 12:03 PM, Matt Burgess  wrote:

> +1 binding
>
> On Fri, Feb 10, 2017 at 11:40 AM, Bryan Bende  wrote:
> > All,
> >
> > Following a solid discussion for the past few days [1] regarding the
> > establishment of Registry as a sub-project of Apache NiFi, I'd like to
> > call a formal vote to record this important community decision and
> > establish consensus.
> >
> > The scope of this project is to define APIs for interacting with
> > resources that one or more NiFi instances may be interested in, such
> > as a flow registry for versioned flows, an extension registry for
> > extensions, and possibly other configuration resources in the future.
> > In addition, this project will provide reference implementations of
> > these registries, with the goal of allowing the community to build a
> > diverse set of implementations, such as a Git provider for versioned
> > flows, or a bintray provider for an extension registry.
> >
> > I am a +1 and looking forward to the future work in this area.
> >
> > The vote will be open for 72 hours and be a majority rule vote.
> >
> > [ ] +1 Establish Registry, a subproject of Apache NiFi
> > [ ]   0 Do not care
> > [ ]  -1 Do not establish Registry, a subproject of Apache NiFi
> >
> > Thanks,
> >
> > Bryan
> >
> > [1] http://mail-archives.apache.org/mod_mbox/nifi-dev/201702.
> mbox/%3CCALo_M19euo2LLy0PVWmE70FzeLhQRcCtX6TC%3DqoiBVfn4zFQMA%40mail.
> gmail.com%3E
>

Re: C++ Style Guide

[Jeremy Dyer]

I'm a big fan of that style as well. I'd be all for it

> On Feb 6, 2017, at 4:51 PM, Aldrin Piri  wrote:
> 
> Marc,
> 
> I think that makes a lot of sense and certainly would be a +1 for the
> effort.
> 
> Would it also make sense to roll in the associated linter [1] and make that
> an available target of build process to help identify compliance?
> 
> [1] https://github.com/google/styleguide/tree/gh-pages/cpplint
> 
>> On Mon, Feb 6, 2017 at 2:51 PM, Marc  wrote:
>> 
>> Hello Everyone,
>> 
>>  I'm submitting a few PRs to the MiNiFi CPP project and would like to
>> discuss a style guide for the C++ development. I'm partial to Google's
>> Style guide:
>> 
>> https://google.github.io/styleguide/cppguide.html
>> 
>>  Are there any objections to this? As I make PRs I'd like to make some
>> changes in favor of this style guide and wanted some support for or against
>> this. I don't intend on making wholesale changes for the sake of the style
>> guide, but instead will make these changes iteratively with my PRs.
>> 
>>  In the future if there is support for it we can create a pre-commit hook
>> to 'beautify the code' with a tool like clang-format or astyle.
>> 
>>  Thoughts for/against this style guide?
>> 
>>  Thanks,
>>  Marc
>> 

Re: [DISCUSS] Official Apache NiFi Docker Image

[Jeremy Dyer]

Team,

I just made the initial commit for the Apache NiFi Docker image
https://github.com/apache/nifi/pull/1372. Please take a look and tell me
your thoughts. Keep in mind this is considered a MVP and we will add the
more sophisticated tuning to the image once we gain traction and get it in
the official dockerhub repo. Adding too many things to it right now could
actually slow that process down so hence the simple image. If you would
like to test the image for yourself here is a convenient one liner to
assist you in doing so.

git clone https://github.com/apache/nifi.git && cd nifi && git fetch origin
pull/1372/head:NIFI-3260 && git checkout NIFI-3260 && cd nifi-docker/1.1.1
&& ./DockerBuild.sh && ./DockerRun.sh && sleep 60 && open
http://localhost:8080/nifi

On Wed, Dec 28, 2016 at 10:22 AM, Jeremy Dyer <jdy...@gmail.com> wrote:

> I think a single instance MVP is certainly where we should start and take
> it from there. Really that might be all we should ever really offer? That
> is all we offer today is a single instance and the end user has the
> capability to cluster those single instances and this wouldn't be any
> different. I also agree that for the first pass unsecured should be fine.
>
> On Wed, Dec 28, 2016 at 10:12 AM, Joe Percivall <jperciv...@apache.org>
> wrote:
>
>> +1
>>
>> Great idea Jeremy. I love even more all of the "I volunteer" statements
>> throughout, haha.
>>
>> Per Joey's point regarding single vs cluster, I'd say it is probably
>> better
>> to get an mvp of standalone first. Also I'd think the use-cases that would
>> be using docker wouldn't need to be clustered. Do you see it differently?
>>
>> Joe
>>
>> On Wed, Dec 28, 2016 at 10:01 AM, Joey Frazee <joey.fra...@icloud.com>
>> wrote:
>>
>> > +1
>> >
>> > I think this is a great idea because there are at least half a dozen or
>> > more Dockerfiles and published images floating around. Having something
>> > that is endorsed and reviewed by the project should help ensure quality.
>> >
>> > One question though: Will the images target a single instance NiFi or a
>> > cluster, e.g., using compose? Or both?
>> >
>> > -joey
>> >
>> > > On Dec 28, 2016, at 8:55 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
>> > >
>> > > Team,
>> > >
>> > > I wanted to discuss getting an official Apache NiFi Docker image
>> similar
>> > to
>> > > other Apache projects like storm [1], httpd [2], thrift [3], etc.
>> > >
>> > > Official Docker images are hosted at http://www.dockerhub.com and
>> made
>> > > available to the Docker runtime of end users without them having to
>> build
>> > > the images themselves. The process of making a Docker image
>> "official",
>> > > meaning that it is validated and reviewed by a community of Docker
>> folks
>> > > for security flaws, best practices, etc, works very closely to how our
>> > > standard contribution process to NiFi works today. We as a community
>> > would
>> > > create our Dockerfile(s) and review them just like we review any JIRA
>> > today
>> > > and then commit that against our codebase.
>> > >
>> > > There is an additional step from there in that once we have a commit
>> > > against our codebase we would need an "ambassador" (I happily
>> volunteer
>> > to
>> > > handle this if there are no objections) who would open a Github Pull
>> > > Request against the official docker image repo [4]. Once that PR has
>> > > successfully been reviewed by the official repo folks it would be
>> hosted
>> > on
>> > > Dockerhub and readily available to end users.
>> > >
>> > > In my mind the steps required to reach this goal would be.
>> > > 1. Create NiFi, MiNiFi, MiNiFi-CPP JIRAs for creating the initial
>> folder
>> > > structure and baseline Dockerfiles in each repo. I also volunteer
>> myself
>> > to
>> > > take this on as well.
>> > > 2. Once JIRA is completed, reviewed, and community thumbs up is given
>> I
>> > > will request the Dockerhub repo handle of "library/apachenifi" with
>> the
>> > > maintainer of that repos contact email as <dev@nifi.apache.org>
>> > > 2a). I suggest we follow the naming structure like
>> > > "library/apachenifi:nifi-1.1.0", "library/apachenifi:minifi-0.1.0",
>> > > "libraryapachenifi:minifi-cpp-0.1.0". This makes our official image
>> much
>> > > more clean than having 3 separate official images for each subproject.
>> > > 3) I will open a PR against [4] with our community Dockerfiles
>> > > 4) After each release I will continue to open pull requests against
>> [4]
>> > to
>> > > ensure the latest releases are present.
>> > >
>> > > Please let me know your thoughts.
>> > >
>> > > [1] - https://hub.docker.com/r/library/storm/
>> > > [2] - https://hub.docker.com/_/httpd/
>> > > [3] - https://hub.docker.com/_/thrift/
>> > > [4] - https://github.com/docker-library/official-images
>> > >
>> > > Thanks,
>> > > Jeremy Dyer
>> >
>>
>
>

Re: [DISCUSS] Official Apache NiFi Docker Image

[Jeremy Dyer]

I think a single instance MVP is certainly where we should start and take
it from there. Really that might be all we should ever really offer? That
is all we offer today is a single instance and the end user has the
capability to cluster those single instances and this wouldn't be any
different. I also agree that for the first pass unsecured should be fine.

On Wed, Dec 28, 2016 at 10:12 AM, Joe Percivall <jperciv...@apache.org>
wrote:

> +1
>
> Great idea Jeremy. I love even more all of the "I volunteer" statements
> throughout, haha.
>
> Per Joey's point regarding single vs cluster, I'd say it is probably better
> to get an mvp of standalone first. Also I'd think the use-cases that would
> be using docker wouldn't need to be clustered. Do you see it differently?
>
> Joe
>
> On Wed, Dec 28, 2016 at 10:01 AM, Joey Frazee <joey.fra...@icloud.com>
> wrote:
>
> > +1
> >
> > I think this is a great idea because there are at least half a dozen or
> > more Dockerfiles and published images floating around. Having something
> > that is endorsed and reviewed by the project should help ensure quality.
> >
> > One question though: Will the images target a single instance NiFi or a
> > cluster, e.g., using compose? Or both?
> >
> > -joey
> >
> > > On Dec 28, 2016, at 8:55 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> > >
> > > Team,
> > >
> > > I wanted to discuss getting an official Apache NiFi Docker image
> similar
> > to
> > > other Apache projects like storm [1], httpd [2], thrift [3], etc.
> > >
> > > Official Docker images are hosted at http://www.dockerhub.com and made
> > > available to the Docker runtime of end users without them having to
> build
> > > the images themselves. The process of making a Docker image "official",
> > > meaning that it is validated and reviewed by a community of Docker
> folks
> > > for security flaws, best practices, etc, works very closely to how our
> > > standard contribution process to NiFi works today. We as a community
> > would
> > > create our Dockerfile(s) and review them just like we review any JIRA
> > today
> > > and then commit that against our codebase.
> > >
> > > There is an additional step from there in that once we have a commit
> > > against our codebase we would need an "ambassador" (I happily volunteer
> > to
> > > handle this if there are no objections) who would open a Github Pull
> > > Request against the official docker image repo [4]. Once that PR has
> > > successfully been reviewed by the official repo folks it would be
> hosted
> > on
> > > Dockerhub and readily available to end users.
> > >
> > > In my mind the steps required to reach this goal would be.
> > > 1. Create NiFi, MiNiFi, MiNiFi-CPP JIRAs for creating the initial
> folder
> > > structure and baseline Dockerfiles in each repo. I also volunteer
> myself
> > to
> > > take this on as well.
> > > 2. Once JIRA is completed, reviewed, and community thumbs up is given I
> > > will request the Dockerhub repo handle of "library/apachenifi" with the
> > > maintainer of that repos contact email as <dev@nifi.apache.org>
> > > 2a). I suggest we follow the naming structure like
> > > "library/apachenifi:nifi-1.1.0", "library/apachenifi:minifi-0.1.0",
> > > "libraryapachenifi:minifi-cpp-0.1.0". This makes our official image
> much
> > > more clean than having 3 separate official images for each subproject.
> > > 3) I will open a PR against [4] with our community Dockerfiles
> > > 4) After each release I will continue to open pull requests against [4]
> > to
> > > ensure the latest releases are present.
> > >
> > > Please let me know your thoughts.
> > >
> > > [1] - https://hub.docker.com/r/library/storm/
> > > [2] - https://hub.docker.com/_/httpd/
> > > [3] - https://hub.docker.com/_/thrift/
> > > [4] - https://github.com/docker-library/official-images
> > >
> > > Thanks,
> > > Jeremy Dyer
> >
>

[DISCUSS] Official Apache NiFi Docker Image

[Jeremy Dyer]

Team,

I wanted to discuss getting an official Apache NiFi Docker image similar to
other Apache projects like storm [1], httpd [2], thrift [3], etc.

Official Docker images are hosted at http://www.dockerhub.com and made
available to the Docker runtime of end users without them having to build
the images themselves. The process of making a Docker image "official",
meaning that it is validated and reviewed by a community of Docker folks
for security flaws, best practices, etc, works very closely to how our
standard contribution process to NiFi works today. We as a community would
create our Dockerfile(s) and review them just like we review any JIRA today
and then commit that against our codebase.

There is an additional step from there in that once we have a commit
against our codebase we would need an "ambassador" (I happily volunteer to
handle this if there are no objections) who would open a Github Pull
Request against the official docker image repo [4]. Once that PR has
successfully been reviewed by the official repo folks it would be hosted on
Dockerhub and readily available to end users.

In my mind the steps required to reach this goal would be.
1. Create NiFi, MiNiFi, MiNiFi-CPP JIRAs for creating the initial folder
structure and baseline Dockerfiles in each repo. I also volunteer myself to
take this on as well.
2. Once JIRA is completed, reviewed, and community thumbs up is given I
will request the Dockerhub repo handle of "library/apachenifi" with the
maintainer of that repos contact email as <dev@nifi.apache.org>
2a). I suggest we follow the naming structure like
"library/apachenifi:nifi-1.1.0", "library/apachenifi:minifi-0.1.0",
"libraryapachenifi:minifi-cpp-0.1.0". This makes our official image much
more clean than having 3 separate official images for each subproject.
3) I will open a PR against [4] with our community Dockerfiles
4) After each release I will continue to open pull requests against [4] to
ensure the latest releases are present.

Please let me know your thoughts.

[1] - https://hub.docker.com/r/library/storm/
[2] - https://hub.docker.com/_/httpd/
[3] - https://hub.docker.com/_/thrift/
[4] - https://github.com/docker-library/official-images

Thanks,
Jeremy Dyer

Re: [ANNOUNCE] New Apache NiFi Committer Jeremy Dyer

[Jeremy Dyer]

Thank you everyone. I'm really pumped to be part of such a thriving community! 
I look forward to working more closely with you all and helping continue your 
existing legacy of building awesome stuff. 

- Jeremy Dyer

Sent from my iPhone
> On Dec 20, 2016, at 8:01 AM, Koji Kawamura <ijokaruma...@apache.org> wrote:
> 
> Congratulations Jeremy!!
> 
> Koji
> 
> On Dec 20, 2016 9:26 PM, "Rob Moran" <rmo...@gmail.com> wrote:
> 
> Thank you and congratulations Jeremy!
> 
> Rob
> 
>> On Tue, Dec 20, 2016 at 7:14 AM, Joe Skora <jsk...@gmail.com> wrote:
>> 
>> Congrats Jeremy, welcome!
>> 
>> On Tue, Dec 20, 2016 at 8:47 AM, Pierre Villard <
>> pierre.villard...@gmail.com
>>> wrote:
>> 
>>> Congrats Jeremy, great to have you!
>>> 
>>> 2016-12-20 6:18 GMT+01:00 Andrew Psaltis <psaltis.and...@gmail.com>:
>>> 
>>>> Congrats Jeremy!!
>>>> 
>>>>> On Mon, Dec 19, 2016 at 9:45 PM, Joe Witt <joe.w...@gmail.com> wrote:
>>>>> 
>>>>> Well done Jeremy and thanks for all your contributions!
>>>>> 
>>>>> On Mon, Dec 19, 2016 at 9:24 PM, Joe Percivall
>>>>> <joeperciv...@yahoo.com.invalid> wrote:
>>>>>> Congrats Jeremy! Very well deserved.
>>>>>> 
>>>>>> 
>>>>>> - - - - - - Joseph Percivalllinkedin.com/in/Percivalle:
>>>>> joeperciv...@yahoo.com
>>>>>> 
>>>>>> 
>>>>>> On Monday, December 19, 2016, 9:13:22 PM EST, Bryan Bende <
>>>>> bbe...@gmail.com> wrote:Congrats and welcome!
>>>>>> 
>>>>>> On Mon, Dec 19, 2016 at 8:52 PM Matt Burgess <mattyb...@apache.org
>>> 
>>>>> wrote:
>>>>>> 
>>>>>> Congratulations Jeremy and welcome! Very well deserved.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Matt
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mon, Dec 19, 2016 at 8:23 PM, Aldrin Piri <ald...@apache.org>
>>>> wrote:
>>>>>> 
>>>>>>> On behalf of the Apache NiFI PMC, I am very pleased to announce
>> that
>>>>>> Jeremy
>>>>>> 
>>>>>>> Dyer has accepted the PMC's invitation to become a committer on
>> the
>>>>> Apache
>>>>>> 
>>>>>>> NiFi project. We greatly appreciate all of Jeremy's hard work and
>>>>> generous
>>>>>> 
>>>>>>> contributions and look forward to continued involvement in the
>>>> project.
>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>>> Jeremy’s contributions include creation a suite of the processors
>>> that
>>>>>> aided
>>>>>> 
>>>>>>> in parsing HTML, build improvement and testing for MiNiFi, as
> well
>>> as
>>>>> many
>>>>>> 
>>>>>>> articles and presentations on using NiFi in new and novel ways.
>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>>> Welcome Jeremy!
>>>>>> 
>>>>>> --
>>>>>> Sent from Gmail Mobile
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Thanks,
>>>> Andrew
>>>> 
>>>> Subscribe to my book: Streaming Data <http://manning.com/psaltis>
>>>> <https://www.linkedin.com/pub/andrew-psaltis/1/17b/306>
>>>> twiiter: @itmdata <http://twitter.com/intent/user?screen_name=itmdata>
>>>> 
>>> 
>> 

MiNiFi-cpp Dynamic Properties

[Jeremy Dyer]

Team,

I wanted to discuss implementation details around dynamic properties for
C++ processors. Currently Processor.cpp prevents any property present in
config.yml and not in the set of supported properties from being read.

In general I'm wondering if it should be the responsibility of each
processor developed to override the setProperty function and handle the
dynamic properties internally or if there should be something like a
"dynamicProperty" variable present in Processor.cpp much like the map that
is currently their for  but rather  in
this case.

The Processor.cpp setProperty logic could then be altered to something like
that if a property read from config.yml is not in the list of supported
properties it can safely assume and considered a dynamic property and then
placed there. Likewise the Processor.cpp getProperty function could be
altered to return from the dynamic property map if the key is not located
in the supported properties map.

I lean more towards the "dynamicProperty" approach but wanted to hear
others opinions.

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

[Jeremy Dyer]

+1 (non-binding) Release this package as nifi-minifi-cpp-0.1.0

Validated signature, resulting assembly artifacts, and builds/packaging for
Ubuntu 16.10 and CentOs 7.2. I also validated a simple flow of tailing
local files and transferring data over site-to-site to NiFi.

On Tue, Nov 29, 2016 at 11:54 AM, Aldrin Piri  wrote:

> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> MiNiFi C++, nifi-minifi-cpp-0.1.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.1.0/nifi-minifi-cpp-0.1.0-source.tar.gz
> GPG armored signature:
>https://dist.apache.org/repos/dist/dev/nifi/nifi-
> minifi-cpp/0.1.0/nifi-minifi-cpp-0.1.0-source.tar.gz.asc
> Source MD5:
>https://dist.apache.org/repos/dist/dev/nifi/nifi-
> minifi-cpp/0.1.0/nifi-minifi-cpp-0.1.0-source.tar.gz.md5
> Source SHA1:
>https://dist.apache.org/repos/dist/dev/nifi/nifi-
> minifi-cpp/0.1.0/nifi-minifi-cpp-0.1.0-source.tar.gz.sha1
> Source SHA256:
>https://dist.apache.org/repos/dist/dev/nifi/nifi-
> minifi-cpp/0.1.0/nifi-minifi-cpp-0.1.0-source.tar.gz.sha256
>
> The Git tag is minifi-cpp-0.1.0-RC1
> The Git commit hash is bd963503586aeb9b24b4ad5a96da9a1a6818a186
> * https://git-wip-us.apache.org/repos/asf?p=nifi-minifi-
> cpp.git;a=commit;h=bd963503586aeb9b24b4ad5a96da9a1a6818a186
> * https://github.com/apache/nifi-minifi-cpp/commit/bd9635035
> 86aeb9b24b4ad5a96da9a1a6818a186
>
> Checksums of nifi-minifi-cpp-0.1.0-source.tar.gz:
> MD5: a7155f53d86ef93e37bf28d6e4a0299f
> SHA1: f3cb105584d79f70edbd6e5bc0908be3731263fd
> SHA256: 62441650684bc2d9631f683b29b3f5f12c3c55b8b1f336badf7f7f0061d47b66
>
>
> 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/release/nifi/KEYS
>
> 15 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?versi
> on=12338046=12319921
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/MINIFI/Release+
> Notes#ReleaseNotes-Versioncpp-0.1.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.1.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

Re: InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

Matt - Your right about just adding a "RouteOnAttribute" processor. I got
so caught up in trying to understand why a retry wasn't getting fired I
lost track of my original goal. I think I have a understanding of why the
"retry" was not getting fired now and that makes perfect sense. I will just
add the "RouteOnAttribute" processor now to check for a 200 or 502 code in
the response.

Thanks

On Fri, Oct 14, 2016 at 12:50 PM, Matt Burgess <mattyb...@apache.org> wrote:

> This might be intended behavior, it appears that only request
> (incoming) flow files get routed to relationships like "retry", but
> you have no incoming request flow file so there is technically nothing
> to retry (the processor will "retry" the next time it runs). In your
> case it sounds like you'd need a RouteOnAttribute for the "response"
> relationship in order to handle responses when there was no request
> flow file.
>
> Alternatively, what would you expect the behavior to be? Would
> responses and requests (if present) be routed to "retry", or would a
> "fake" request be generated for a GET with no incoming flow file? In
> the former case you'd have two types of flow files to deal with (is it
> request or response?), in the latter case the flow file would likely
> only be an indication that a GET occurred, as it would have no
> content, and if the retry route were connected back to InvokeHttp, it
> seems functionally the same as the InvokeHttp running on its own
> schedule (it would try the GET again later when scheduled).  Not
> saying either is necessarily bad, just wanted to get your thoughts.
>
> Thanks,
> Matt
>
> On Fri, Oct 14, 2016 at 12:29 PM, Jeremy Dyer <jdy...@gmail.com> wrote:
> > Matt - No, I am not seeing this expected behavior. Nothing is being
> routed
> > to "retry" as expected. IF I set "Always Output Response" = true the
> > "Response" relationship is triggered and even in there you can see the
> > "invoke.http.statuscode=502" I have attached a screenshot to show you
> what I
> > mean. Looking at the code the only possible explanation for this would be
> > that the incoming flowfile == null. Since my "InvokeHTTP" is a simple
> "GET"
> > with no incoming flowfile I believe that the line at [1] is not being
> > invoked as expected because the property at [2] is not set. However I do
> not
> > want to set that property.
> >
> > [1]
> > https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596
> > [2]
> > https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586
> >
> > On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess <mattyb...@apache.org>
> wrote:
> >>
> >> Jeremy,
> >>
> >> The code implies that 502 responses (actually all 5xx responses) are
> >> routed to "retry" [1]. Are you not seeing that?
> >>
> >> Regards,
> >> Matt
> >>
> >> [1]
> >> https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906
> >>
> >> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> >> > I'm monitoring some micro services that sit behind an Nginx reverse
> >> > proxy.
> >> > The idea is simple I want to fire off an alert if I get a "502 - Bad
> >> > Gateway" response from Nginx which would mean that something has
> caused
> >> > the
> >> > micro service to crash and then have NiFi attempt to restart the micro
> >> > service.
> >> >
> >> > However no relationship is being invoked when a 502 response code is
> >> > returned? Works great for 200 or even 500 but not getting any output
> >> > what
> >> > so ever for a 502? Any ideas?
> >> >
> >> > Thanks,
> >> > Jeremy Dyer
> >
> >
>

Re: InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

Matt - No, I am not seeing this expected behavior. Nothing is being routed
to "retry" as expected. IF I set "Always Output Response" = true the
"Response" relationship is triggered and even in there you can see the
"invoke.http.statuscode=502" I have attached a screenshot to show you what
I mean. Looking at the code the only possible explanation for this would be
that the incoming flowfile == null. Since my "InvokeHTTP" is a simple "GET"
with no incoming flowfile I believe that the line at [1] is not being
invoked as expected because the property at [2] is not set. However I do
not want to set that property.

[1]
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596
[2]
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586

On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess <mattyb...@apache.org> wrote:

> Jeremy,
>
> The code implies that 502 responses (actually all 5xx responses) are
> routed to "retry" [1]. Are you not seeing that?
>
> Regards,
> Matt
>
> [1] https://github.com/apache/nifi/blob/master/nifi-nar-
> bundles/nifi-standard-bundle/nifi-standard-processors/src/
> main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906
>
> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> > I'm monitoring some micro services that sit behind an Nginx reverse
> proxy.
> > The idea is simple I want to fire off an alert if I get a "502 - Bad
> > Gateway" response from Nginx which would mean that something has caused
> the
> > micro service to crash and then have NiFi attempt to restart the micro
> > service.
> >
> > However no relationship is being invoked when a 502 response code is
> > returned? Works great for 200 or even 500 but not getting any output what
> > so ever for a 502? Any ideas?
> >
> > Thanks,
> > Jeremy Dyer
>

Re: Issue on creating Custom Processor - Salesforce

[Jeremy Dyer]

Shankhamajumdar - I'd be glad to help you out but how about you email me
personally outside of this thread since this project isn't formally part of
the Apache community. Look forward to hearing from you

On Fri, Oct 14, 2016 at 8:29 AM, shankhamajumdar <
shankha.majum...@lexmark.com> wrote:

> Hi Jeremy,
>
> There is one more issue. Actually I did the build inside
> D:\nifi-addons-master\Services\nifi-salesforce-
> service\nifi-salesforce-api-nar
> directory successfully. But ideally I should build inside
> D:\nifi-addons-master\Services directory which is failing.
>
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] Child module D:\nifi-addons-master\Services\nifi-google-auth-
> service
> of
> D:\nifi-addons-master\Services\pom.xml does not exist @
>  @
>
> I do not see nifi-google-auth-service as well in the
> D:\nifi-addons-master\Services directory.
>
> Regards,
> Shankha
>
>
>
>
>
> --
> View this message in context: http://apache-nifi-developer-
> list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-
> tp13603p13610.html
> Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>

InvokeHTTP - no relationship invoked for 502 response

[Jeremy Dyer]

I'm monitoring some micro services that sit behind an Nginx reverse proxy.
The idea is simple I want to fire off an alert if I get a "502 - Bad
Gateway" response from Nginx which would mean that something has caused the
micro service to crash and then have NiFi attempt to restart the micro
service.

However no relationship is being invoked when a 502 response code is
returned? Works great for 200 or even 500 but not getting any output what
so ever for a 502? Any ideas?

Thanks,
Jeremy Dyer

Re: Issue on creating Custom Processor - Salesforce

[Jeremy Dyer]

Shankhamajumdar - You are seeing this because the Salesforce controller 
services haven't been built yet. If you navigate to the {nifi_addons}/services 
directory and run a mvn clean install and then reattempt to build the 
processors the error should go away. 

- Jeremy Dyer

> On Oct 14, 2016, at 2:03 AM, shankhamajumdar <shankha.majum...@lexmark.com> 
> wrote:
> 
> Hi,
> 
> I am trying to create the Custom Salesforce Processor for Nifi but getting
> the below error while doing the maven build.
> 
> [ERROR] Failed to execute goal on project nifi-salesforce-processors: Could
> not
> resolve dependencies for project
> com.jeremydyer.nifi:nifi-salesforce-processors:
> jar:1.0.0: Could not find artifact
> com.jeremydyer.nifi:nifi-salesforce-api:jar:1
> .0.0 in central (https://repo1.maven.org/maven2) -> [Help 1]
> 
> The maven build for other Custom Processors are working fine.
> 
> Regards,
> Shankha
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/Issue-on-creating-Custom-Processor-Salesforce-tp13603.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Enumerating processors, queues, etc.

[Jeremy Dyer]

Mark,

ok that makes sense. I have created a jira for this improvement
https://issues.apache.org/jira/browse/NIFI-1805

On Fri, Apr 22, 2016 at 12:27 PM, Mark Payne <marka...@hotmail.com> wrote:

> Jeremy,
>
> It should be relatively easy. In FlowController, we would have to update
> getGroupStatus() to set the values on ConnectionStatus
> and of course update ConnectionStatus to have getters & setters for the
> new values. That should be about it, I think.
>
> -Mark
>
>
> > On Apr 22, 2016, at 12:17 PM, Jeremy Dyer <jdy...@gmail.com> wrote:
> >
> > Mark,
> >
> > What would the process look like for doing that? Would that be something
> > trivial or require some reworking?
> >
> > On Fri, Apr 22, 2016 at 10:26 AM, Mark Payne <marka...@hotmail.com>
> wrote:
> >
> >> I definitely don't think we should be exposing the FlowController to a
> >> Reporting Task.
> >> However, I think exposing information about whether or not backpressure
> is
> >> being applied
> >> (or even is configured) is a very reasonable idea.
> >>
> >> -Mark
> >>
> >>
> >>> On Apr 22, 2016, at 10:22 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> >>>
> >>> I could see the argument for not making that available. What about some
> >>> sort of reference that would allow the ReportingTask to to determine if
> >>> backpressure is being applied to a Connection? It currently seems you
> can
> >>> see the number of bytes and/or objects count queued in a connection but
> >>> don't have any reference to the values a user has setup for
> backpressure
> >> in
> >>> the UI. Is there a way to get those values in the scope of the
> >>> ReportingTask?
> >>>
> >>> On Fri, Apr 22, 2016 at 10:03 AM, Bryan Bende <bbe...@gmail.com>
> wrote:
> >>>
> >>>> I think the only way you could do it directly without the REST API is
> by
> >>>> having access to the FlowController,
> >>>> but that is purposely not exposed to extension points... actually
> >>>> StandardFlowController is what implements the
> >>>> EventAccess interface which ends up providing the path way to the
> status
> >>>> objects.
> >>>>
> >>>> I would have to defer to Joe, Mark, and others about whether we would
> >> want
> >>>> to expose direct access to components
> >>>> through controller services, or some other extension point.
> >>>>
> >>>> On Fri, Apr 22, 2016 at 9:46 AM, Jeremy Dyer <jdy...@gmail.com>
> wrote:
> >>>>
> >>>>> Bryan,
> >>>>>
> >>>>> The ReportingTask enumeration makes sense and was helpful for
> something
> >>>>> else I am working on as well.
> >>>>>
> >>>>> Like Joe however I'm looking for a way to not just get the *Status
> >>>> objects
> >>>>> but rather start and stop processors. Is there a way to do that from
> >> the
> >>>>> ReportContext scope? I imagine you could pull the Processor "Id" from
> >> the
> >>>>> ProcessorStatus and then use the REST API but was looking for
> something
> >>>>> more direct than having to use the REST API
> >>>>>
> >>>>>
> >>>>> On Fri, Apr 22, 2016 at 9:23 AM, Bryan Bende <bbe...@gmail.com>
> wrote:
> >>>>>
> >>>>>> Hi Joe,
> >>>>>>
> >>>>>> I'm not sure if a controller service can do this, but a
> ReportingTask
> >>>> has
> >>>>>> access to similar information.
> >>>>>>
> >>>>>> A ReportingTask gets access to a ReportingContext, which can access
> >>>>>> EventAccess which can access ProcessGroupStatus.
> >>>>>>
> >>>>>> From ProcessGroupStatus you are at the root process group and can
> >>>>> enumerate
> >>>>>> the flow:
> >>>>>>
> >>>>>> private Collection connectionStatus = new
> >>>>> ArrayList<>();
> >>>>>> private Collection processorStatus = new
> >>>> ArrayList<>();
> >>>>>> private Collection processGroupStatus = new
> >>>>>> ArrayList<>();
> >>>>>> private Collection
> remoteProcessGroupStatus
> >> =
> >>>>> new
> >>>>>> ArrayList<>();
> >>>>>> private Collection inputPortStatus = new ArrayList<>();
> >>>>>> private Collection outputPortStatus = new ArrayList<>();
> >>>>>>
> >>>>>> Not sure if that is what you were looking for.
> >>>>>>
> >>>>>> -Bryan
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Apr 22, 2016 at 8:25 AM, Joe Skora <jsk...@gmail.com>
> wrote:
> >>>>>>
> >>>>>>> Is it possible and if so what is the best way for a controller
> >>>> service
> >>>>> to
> >>>>>>> get the collection of all processors or queues?
> >>>>>>>
> >>>>>>> The goal being to iterate over the collection of processors or
> queues
> >>>>> to
> >>>>>>> gather information or make adjustments to the flow.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>

Re: Enumerating processors, queues, etc.

[Jeremy Dyer]

Mark,

What would the process look like for doing that? Would that be something
trivial or require some reworking?

On Fri, Apr 22, 2016 at 10:26 AM, Mark Payne <marka...@hotmail.com> wrote:

> I definitely don't think we should be exposing the FlowController to a
> Reporting Task.
> However, I think exposing information about whether or not backpressure is
> being applied
> (or even is configured) is a very reasonable idea.
>
> -Mark
>
>
> > On Apr 22, 2016, at 10:22 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> >
> > I could see the argument for not making that available. What about some
> > sort of reference that would allow the ReportingTask to to determine if
> > backpressure is being applied to a Connection? It currently seems you can
> > see the number of bytes and/or objects count queued in a connection but
> > don't have any reference to the values a user has setup for backpressure
> in
> > the UI. Is there a way to get those values in the scope of the
> > ReportingTask?
> >
> > On Fri, Apr 22, 2016 at 10:03 AM, Bryan Bende <bbe...@gmail.com> wrote:
> >
> >> I think the only way you could do it directly without the REST API is by
> >> having access to the FlowController,
> >> but that is purposely not exposed to extension points... actually
> >> StandardFlowController is what implements the
> >> EventAccess interface which ends up providing the path way to the status
> >> objects.
> >>
> >> I would have to defer to Joe, Mark, and others about whether we would
> want
> >> to expose direct access to components
> >> through controller services, or some other extension point.
> >>
> >> On Fri, Apr 22, 2016 at 9:46 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
> >>
> >>> Bryan,
> >>>
> >>> The ReportingTask enumeration makes sense and was helpful for something
> >>> else I am working on as well.
> >>>
> >>> Like Joe however I'm looking for a way to not just get the *Status
> >> objects
> >>> but rather start and stop processors. Is there a way to do that from
> the
> >>> ReportContext scope? I imagine you could pull the Processor "Id" from
> the
> >>> ProcessorStatus and then use the REST API but was looking for something
> >>> more direct than having to use the REST API
> >>>
> >>>
> >>> On Fri, Apr 22, 2016 at 9:23 AM, Bryan Bende <bbe...@gmail.com> wrote:
> >>>
> >>>> Hi Joe,
> >>>>
> >>>> I'm not sure if a controller service can do this, but a ReportingTask
> >> has
> >>>> access to similar information.
> >>>>
> >>>> A ReportingTask gets access to a ReportingContext, which can access
> >>>> EventAccess which can access ProcessGroupStatus.
> >>>>
> >>>> From ProcessGroupStatus you are at the root process group and can
> >>> enumerate
> >>>> the flow:
> >>>>
> >>>> private Collection connectionStatus = new
> >>> ArrayList<>();
> >>>> private Collection processorStatus = new
> >> ArrayList<>();
> >>>> private Collection processGroupStatus = new
> >>>> ArrayList<>();
> >>>> private Collection remoteProcessGroupStatus
> =
> >>> new
> >>>> ArrayList<>();
> >>>> private Collection inputPortStatus = new ArrayList<>();
> >>>> private Collection outputPortStatus = new ArrayList<>();
> >>>>
> >>>> Not sure if that is what you were looking for.
> >>>>
> >>>> -Bryan
> >>>>
> >>>>
> >>>> On Fri, Apr 22, 2016 at 8:25 AM, Joe Skora <jsk...@gmail.com> wrote:
> >>>>
> >>>>> Is it possible and if so what is the best way for a controller
> >> service
> >>> to
> >>>>> get the collection of all processors or queues?
> >>>>>
> >>>>> The goal being to iterate over the collection of processors or queues
> >>> to
> >>>>> gather information or make adjustments to the flow.
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: Enumerating processors, queues, etc.

[Jeremy Dyer]

I could see the argument for not making that available. What about some
sort of reference that would allow the ReportingTask to to determine if
backpressure is being applied to a Connection? It currently seems you can
see the number of bytes and/or objects count queued in a connection but
don't have any reference to the values a user has setup for backpressure in
the UI. Is there a way to get those values in the scope of the
ReportingTask?

On Fri, Apr 22, 2016 at 10:03 AM, Bryan Bende <bbe...@gmail.com> wrote:

> I think the only way you could do it directly without the REST API is by
> having access to the FlowController,
> but that is purposely not exposed to extension points... actually
> StandardFlowController is what implements the
> EventAccess interface which ends up providing the path way to the status
> objects.
>
> I would have to defer to Joe, Mark, and others about whether we would want
> to expose direct access to components
> through controller services, or some other extension point.
>
> On Fri, Apr 22, 2016 at 9:46 AM, Jeremy Dyer <jdy...@gmail.com> wrote:
>
> > Bryan,
> >
> > The ReportingTask enumeration makes sense and was helpful for something
> > else I am working on as well.
> >
> > Like Joe however I'm looking for a way to not just get the *Status
> objects
> > but rather start and stop processors. Is there a way to do that from the
> > ReportContext scope? I imagine you could pull the Processor "Id" from the
> > ProcessorStatus and then use the REST API but was looking for something
> > more direct than having to use the REST API
> >
> >
> > On Fri, Apr 22, 2016 at 9:23 AM, Bryan Bende <bbe...@gmail.com> wrote:
> >
> > > Hi Joe,
> > >
> > > I'm not sure if a controller service can do this, but a ReportingTask
> has
> > > access to similar information.
> > >
> > > A ReportingTask gets access to a ReportingContext, which can access
> > > EventAccess which can access ProcessGroupStatus.
> > >
> > > From ProcessGroupStatus you are at the root process group and can
> > enumerate
> > > the flow:
> > >
> > > private Collection connectionStatus = new
> > ArrayList<>();
> > > private Collection processorStatus = new
> ArrayList<>();
> > > private Collection processGroupStatus = new
> > > ArrayList<>();
> > > private Collection remoteProcessGroupStatus =
> > new
> > > ArrayList<>();
> > > private Collection inputPortStatus = new ArrayList<>();
> > > private Collection outputPortStatus = new ArrayList<>();
> > >
> > > Not sure if that is what you were looking for.
> > >
> > > -Bryan
> > >
> > >
> > > On Fri, Apr 22, 2016 at 8:25 AM, Joe Skora <jsk...@gmail.com> wrote:
> > >
> > > > Is it possible and if so what is the best way for a controller
> service
> > to
> > > > get the collection of all processors or queues?
> > > >
> > > > The goal being to iterate over the collection of processors or queues
> > to
> > > > gather information or make adjustments to the flow.
> > > >
> > >
> >
>

Re: Enumerating processors, queues, etc.

[Jeremy Dyer]

Bryan,

The ReportingTask enumeration makes sense and was helpful for something
else I am working on as well.

Like Joe however I'm looking for a way to not just get the *Status objects
but rather start and stop processors. Is there a way to do that from the
ReportContext scope? I imagine you could pull the Processor "Id" from the
ProcessorStatus and then use the REST API but was looking for something
more direct than having to use the REST API


On Fri, Apr 22, 2016 at 9:23 AM, Bryan Bende  wrote:

> Hi Joe,
>
> I'm not sure if a controller service can do this, but a ReportingTask has
> access to similar information.
>
> A ReportingTask gets access to a ReportingContext, which can access
> EventAccess which can access ProcessGroupStatus.
>
> From ProcessGroupStatus you are at the root process group and can enumerate
> the flow:
>
> private Collection connectionStatus = new ArrayList<>();
> private Collection processorStatus = new ArrayList<>();
> private Collection processGroupStatus = new
> ArrayList<>();
> private Collection remoteProcessGroupStatus = new
> ArrayList<>();
> private Collection inputPortStatus = new ArrayList<>();
> private Collection outputPortStatus = new ArrayList<>();
>
> Not sure if that is what you were looking for.
>
> -Bryan
>
>
> On Fri, Apr 22, 2016 at 8:25 AM, Joe Skora  wrote:
>
> > Is it possible and if so what is the best way for a controller service to
> > get the collection of all processors or queues?
> >
> > The goal being to iterate over the collection of processors or queues to
> > gather information or make adjustments to the flow.
> >
>

Trouble Starting Custom Salesforce Streaming API Controller Service

[Jeremy Dyer]

I have created a custom Controller Service for connecting to the Salesforce
Streaming API to receive realtime Salesforce.com activity. Doing so
requires using the CometD Bayeux Protocol and Jetty. I seem to be running
into some class incompatibility issues when I attempt to enable the
service. I was hoping someone might have an idea what i'm doing wrong here
or what classes they suspect might be giving me this issue?

PS - The only extra dependencies I have added to my pom.xml are the CometD
libraries version 3.0.9. I'm using the Jetty version already available.


2016-04-04 06:32:41,003 ERROR [pool-27-thread-8]
o.a.n.c.s.StandardControllerServiceNode
java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_45]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
~[na:1.8.0_45]
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
~[na:1.8.0_45]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
~[na:1.8.0_45]
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
~[na:1.8.0_45]
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
~[na:1.8.0_45]
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
~[na:1.8.0_45]
at java.security.AccessController.doPrivileged(Native Method)
~[na:1.8.0_45]
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
~[na:1.8.0_45]
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
~[na:1.8.0_45]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
~[na:1.8.0_45]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.oauthLogin(SalesforceStreamingService.java:273)
~[na:na]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.getClient(SalesforceStreamingService.java:184)
~[na:na]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.onEnabled(SalesforceStreamingService.java:146)
~[na:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_45]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_45]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_45]
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:102)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
org.apache.nifi.controller.service.StandardControllerServiceNode$1.run(StandardControllerServiceNode.java:285)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[na:1.8.0_45]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_45]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[na:1.8.0_45]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
2016-04-04 06:32:41,003 ERROR [pool-27-thread-8]
o.a.n.c.s.StandardControllerServiceNode Failed to invoke @OnEnabled method
of SalesforceStreamingService[id=b8589356-88f5-48b2-9d53-383c6a336d51] due
to java.lang.IncompatibleClassChangeError: Implementing class

Thanks,
Jeremy Dyer

Trouble Starting Custom Salesforce Streaming API Controller Service

[Jeremy Dyer]

I have created a custom Controller Service for connecting to the Salesforce
Streaming API to receive realtime Salesforce.com activity. Doing so
requires using the CometD Bayeux Protocol and Jetty. I seem to be running
into some class incompatibility issues when I attempt to enable the
service. I was hoping someone might have an idea what i'm doing wrong here
or what classes they suspect might be giving me this issue?

PS - The only extra dependencies I have added to my pom.xml are the CometD
libraries version 3.0.9. I'm using the Jetty version already available.


2016-04-04 06:32:41,003 ERROR [pool-27-thread-8]
o.a.n.c.s.StandardControllerServiceNode
java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_45]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
~[na:1.8.0_45]
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
~[na:1.8.0_45]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
~[na:1.8.0_45]
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
~[na:1.8.0_45]
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
~[na:1.8.0_45]
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
~[na:1.8.0_45]
at java.security.AccessController.doPrivileged(Native Method)
~[na:1.8.0_45]
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
~[na:1.8.0_45]
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
~[na:1.8.0_45]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
~[na:1.8.0_45]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.oauthLogin(SalesforceStreamingService.java:273)
~[na:na]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.getClient(SalesforceStreamingService.java:184)
~[na:na]
at
com.jeremydyer.salesforce.service.SalesforceStreamingService.onEnabled(SalesforceStreamingService.java:146)
~[na:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_45]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_45]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_45]
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:102)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
org.apache.nifi.controller.service.StandardControllerServiceNode$1.run(StandardControllerServiceNode.java:285)
~[nifi-framework-core-0.5.1.1.1.2.0-32.jar:0.5.1.1.1.2.0-32]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[na:1.8.0_45]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_45]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[na:1.8.0_45]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
2016-04-04 06:32:41,003 ERROR [pool-27-thread-8]
o.a.n.c.s.StandardControllerServiceNode Failed to invoke @OnEnabled method
of SalesforceStreamingService[id=b8589356-88f5-48b2-9d53-383c6a336d51] due
to java.lang.IncompatibleClassChangeError: Implementing class

Re: [ANNOUNCE] New Apache NiFi Committer Oleg Zhurakousky

[Jeremy Dyer]

Congrats Oleg!

Sent from my iPhone

> On Mar 15, 2016, at 9:01 PM, Ricky Saltzer  wrote:
> 
> Big congrats!
>> On Mar 15, 2016 8:42 PM, "Michael Moser"  wrote:
>> 
>> Yes, welcome Oleg!  Your hard work is very much appreciated by everyone.
>> 
>> -- Mike
>> 
>> 
>>> On Tue, Mar 15, 2016 at 8:22 PM, Matt Burgess  wrote:
>>> 
>>> Congratulations! Well deserved.
>>> 
 On Mar 15, 2016, at 8:17 PM, Tony Kurc  wrote:
 
 On behalf of the Apache NiFI PMC, I am very pleased to announce that
>> Oleg
 Zhurakousky has accepted the PMC's invitation to become a committer on
>>> the
 Apache NiFi project. We greatly appreciate all of Oleg's hard work and
 generous contributions to the project. We look forward to his continued
 involvement in the project.
 
 Some highlights of Oleg's contributions include identifying and
>>> mitigating
 some challenging framework bugs, amqp support in 0.5.x, and some pretty
 exciting spring support slated for 0.6.x. As I have noticed, many of
>> you
 have already had the opportunity to interact with Oleg on the mailing
 lists, the jiras, and pull request comments. I, for one, look forward
>> to
 the continued community support!
 
 Welcome and congratulations!
 
 Tony
>> 

Re: [ANNOUNCE] New Apache NiFi Committer Matt Burgess

[Jeremy Dyer]

Congratulations Matt. Look forward to consuming all your future work

> On Mar 4, 2016, at 2:30 PM, Ricky Saltzer  wrote:
> 
> Congratulations!
> 
>> On Fri, Mar 4, 2016 at 2:11 PM, Edmon Begoli  wrote:
>> 
>> Congrats, Matt. I have seen Matt's previous open source code contributions,
>> and I can attest that he is an expert programmer.
>> 
>> Edmon
>> 
>>> On Fri, Mar 4, 2016 at 2:02 PM, Joe Witt  wrote:
>>> 
>>> Congrats Matthew and very much welcome your contributions to the
>>> project in terms of reviews, code, and also blogs to help drive
>>> awareness and feedback of those capabilities.
>>> 
>>> Thanks
>>> Joe
>>> 
 On Fri, Mar 4, 2016 at 2:00 PM, Tony Kurc  wrote:
 On behalf of the Apache NiFI PMC, I am very pleased to announce that
>> Matt
 Burgess has accepted the PMC's invitation to become a committer on the
 Apache NiFi project. We greatly appreciate all of Matt's hard work and
 generous contributions to the project. We look forward to his continued
 involvement in the project.
 
 Matt has taken lead on some of our longer standing feature requests as
>>> well
 as representing the community well in the blogosphere and twitterverse.
 We're delighted to have him on board as a committer now!
 
 Tony
> 
> 
> 
> -- 
> Ricky Saltzer
> http://www.cloudera.com

Re: 3rd Party Dependencies

[Jeremy Dyer]

Joe and Oleg,

Thank you both for the information. Joe I agree with your point that maven
should be leveraged as much as possible. I will have to check with the
original author of the code to see if publishing to some maven repository
would be allowed. Fingers crossed.

Oleg that is very helpful information for sure and if the maven repository
publishing becomes a road block I will certainly fall back to this approach.

Thanks

On Mon, Feb 22, 2016 at 8:18 AM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> Jeremy
>
> Actually the new JMS support which is going in 0.6 answers your exact
> question since with this new support we are supporting non-OS JMS providers
> (e.g., IBM, Tibco etc).
> Basically you can look at https://github.com/apache/nifi/pull/222 and see
> what’s going on (in ControllerServices specifically ), but in the nutshell,
> user points to the directory containing additional resources that needs to
> be added to the class path (e.g., JARs etc.)
>
> Oleg
>
> On Feb 22, 2016, at 8:07 AM, Jeremy Dyer <jdy...@gmail.com jdy...@gmail.com>> wrote:
>
> What would be the recommended way to include 3rd party dependencies for
> building a custom processor that are not present in the public maven
> repository? Local lib directory or ???
>
>

3rd Party Dependencies

[Jeremy Dyer]

What would be the recommended way to include 3rd party dependencies for
building a custom processor that are not present in the public maven
repository? Local lib directory or ???

Re: Issue in Custom Processor in 0.4.1 version

[Jeremy Dyer]

Venkat,

Are you seeing any sort of error or warning in your nifi-app.log file?
Could you pass along your nifi-app.log file?

On Mon, Feb 22, 2016 at 5:10 AM, Venkat Sgk  wrote:

> Hi Team,
>
> We are using apache Nifi 0.4.1 and trying to write custom processor to
> convert CSV to avro.
> when modifying existing code and generated .nar file. When .nar is placed
> in lib directory, and started nifi server we were not able to access nifi (
> http://localhost:8080/nifi/).
>
> We checked the nifi status with status-nifi.bat it is saying server is
> running..
>
> We have seen this feature convert CSV to avro is available in 0.5.0
> version. ( InferAvroSchema).
>
>
> Could you please suggest how to fix this issue..
>
>
> Thanks,
> Venkat
>

Re: java.lang.UnsatisfiedLinkError in PutHDFS with snappy compression.

[Jeremy Dyer]

Shweta,

Looks like your missing the snappy native library. I have seen this several
times before. Assuming your on a linux machine you have 2 options. You can
copy the libsnappy.so native library to your JAVA_HOME/jre/lib native
directory. Or you can set LD_LIBRARY_PATH to point to where your
libsnappy.so native library is located on the machine.

I believe if you closely examine the files that are being written to HDFS
with a .snappy extension you will see that in fact that are not actually
snappy compressed.

Jeremy Dyer

On Sat, Feb 6, 2016 at 1:04 PM, Joe Witt <joe.w...@gmail.com> wrote:

> Can you show what is in your core-site.xml and the proc properties.
> Also can you show the full log output?
>
> Thanks
> Joe
>
> On Sat, Feb 6, 2016 at 9:11 AM, shweta <shweta.agg1...@gmail.com> wrote:
> > Hi All,
> >
> > I'm getting a java.lang.UnsatisfiedLinkError while adding data into
> PutHDFS
> > processor with compression codec as snappy. The error message says
> "Failed
> > to write to HDFS due to
> > org.apache.hadoop.util.NativeCodeloader.build.SupportsSnappy()Z.
> >
> > Inspite of this error, .snappy files are being written in my Hdfs.
> >
> > Has anyone faced a similar issue before or can provide any pointers.
> >
> > Thanks,
> > Shweta
> >
> >
> >
> > --
> > View this message in context:
> http://apache-nifi-developer-list.39713.n7.nabble.com/java-lang-UnsatisfiedLinkError-in-PutHDFS-with-snappy-compression-tp7182.html
> > Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>

Re: Javadoc

[Jeremy Dyer]

my apologizes the command should be "mvn javadoc:aggregate" instead of "mvn
javadoc:generate"

On Sun, Jan 17, 2016 at 3:18 PM, Jeremy Dyer <jdy...@gmail.com> wrote:

> Devin I'm not sure of the presence of the javadocs on nifi.apache.org but
> assuming your on a linux/os x machine with git, java, and maven already
> installed the quickest way to get the latest javadocs would be the run "git
> clone https://github.com/apache/nifi.git && cd nifi && mvn
> javadoc:generate". This should generate the javadocs in
> nifi/target/site/apidocs. Hope this helps.
>
> On Sun, Jan 17, 2016 at 2:38 PM, Devin Fisher <
> devin.fis...@perfectsearchcorp.com> wrote:
>
>> Might be a silly question but I can't find a link the Javadocs anywhere on
>> your website. I've googled for it and only find the reference to the
>> Javadocs in the NiFi Developer’s Guide
>> <https://nifi.apache.org/developer-guide.html>. I'm hopeful that I'm just
>> not seeing it. If not, what is the recommended way to get a hold of it?
>>
>> Also, thanks in advanced.
>>
>> Devin
>>
>
>

Re: Javadoc

[Jeremy Dyer]

Devin I'm not sure of the presence of the javadocs on nifi.apache.org but
assuming your on a linux/os x machine with git, java, and maven already
installed the quickest way to get the latest javadocs would be the run "git
clone https://github.com/apache/nifi.git && cd nifi && mvn
javadoc:generate". This should generate the javadocs in
nifi/target/site/apidocs. Hope this helps.

On Sun, Jan 17, 2016 at 2:38 PM, Devin Fisher <
devin.fis...@perfectsearchcorp.com> wrote:

> Might be a silly question but I can't find a link the Javadocs anywhere on
> your website. I've googled for it and only find the reference to the
> Javadocs in the NiFi Developer’s Guide
> . I'm hopeful that I'm just
> not seeing it. If not, what is the recommended way to get a hold of it?
>
> Also, thanks in advanced.
>
> Devin
>