[RESULT][VOTE] Release Apache NiFi 0.4.1 (rc1)

[Joe Witt]

Hello Apache NiFi Community

The release of Apache NiFi 0.4.1 passes with

5 +1 (binding) votes
2 +1 (non-binding) votes
0 -1 votes

This release is an incremental/bug fix release building on the many
improvements of 0.4.0.

Here is the community vote thread:
http://s.apache.org/vote041

Thanks
Joe

On Mon, Dec 21, 2015 at 10:07 AM, Joe Skora  wrote:
> +1 (non-binding) checksums good, builds and runs without any problems
>
> On Sat, Dec 19, 2015 at 10:45 AM, Joe Witt  wrote:
>
>> Hello NiFi Community,
>>
>> I am pleased to be calling this vote for the source release of Apache
>> NiFi 0.4.1.
>>
>> The source zip, including signatures, digests, and associated
>> convenience binaries can be found at
>>   https://dist.apache.org/repos/dist/dev/nifi/nifi-0.4.1/
>>
>> The staged maven artifacts of the build can be found at
>>   https://repository.apache.org/content/repositories/orgapachenifi-1067
>>
>> The Git tag is nifi-0.4.1-RC1
>> The Git commit ID is d624ea48665041ffd9aa4f246b374bde10cfc878
>>
>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=d624ea48665041ffd9aa4f246b374bde10cfc878
>>
>> Checksums of NiFi 0.4.0 Source Release
>> MD5: 0e6e4dcf079a771d381b2031b4b89de1
>> SHA1: 045466c7efed5331119eff0b84bbe29ce7d9baa3
>>
>> 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
>>
>> 17 issues were resolved for this release
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12334375
>>
>> Release note highlights
>>
>> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.4.1
>>
>> Migration/Upgrade guidance
>>   https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance
>>   https://cwiki.apache.org/confluence/display/NIFI/Upgrading+NiFi
>>
>> 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 Apache NiFi 0.4.1
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because...
>>

Re: Input Forbidden Requirement

[Ian Moran]

To toss in another instance where this change can act against valid
use-cases, consider any instance where you might want to use the Expression
Language to cause one of these 'source' processors to not only run on a
'trigger', but also run more dynamically. Previously, you could potentially
use ExtractText to set up Flowfile attributes you could then reference in
GetFile's Input Directory property, allowing you to specifically target
certain sub-directories for example. Without the ability to route
attribute-laden Flowfiles to GetFile, however, you're limited to only using
Environment variables with the expression language. Still useful in some
instances, but certainly not as robust.

I'm just thinking 'out loud' here, but instead of outright disallowing
incoming connections to processors that are output only, would it be
possible to give some visual indication to the user that the *content* of
the Flowfile will be ignored, and most likely overwritten, but still allow
them to utilize the connection to trigger the processor to run (and
possibly deliver attributes for the Expression Language's use)?

On Tue, Dec 22, 2015 at 11:53 AM, Ricky Saltzer  wrote:

> Aha, that makes sense. Thanks for the explanation! I do agree that it could
> be useful to have control over when those types of processors execute.
>



-- 

*Ian Moran | **Associate Software Developer** | Saggezza*



Email: *ian.mo...@saggezza.com* | Office: 312-267-2929

@saggezza_inc  | LinkedIn
 | www.saggezza.com​

Re: Input Forbidden Requirement

[Ricky Saltzer]

Aha, that makes sense. Thanks for the explanation! I do agree that it could
be useful to have control over when those types of processors execute.

Re: Error: is not the most recent version of this flow file within this session

[xmlking]

Thanks Richard.
I will test it tomorrow.
Sumo
Sent from my iPad

> On Dec 21, 2015, at 11:25 PM, Richard Miskin  wrote:
> 
> Hi Sumanth,
> 
> I think you need to assign the return of putAllAttributes() to ff. A new
> FlowFile is created as part of that call.
> 
> Cheers,
> Richard
> 
> On Tuesday, 22 December 2015, Sumanth Chinthagunta 
> wrote:
> 
>> I am creating a new flowFile in my processor’s onTrigger method and
>> getting following error!
>> Please advice if I am doing anything wrong …..
>> 
>> My requirement is: I need to create a new outgoing flowFile with a set of
>> derived  attributes and route to success path.
>> 
>> ```groovy
>> public void onTrigger(ProcessContext context, ProcessSession session)
>> throws ProcessException {
>> FlowFile ff =  session.create()
>> session.putAllAttributes(ff,[summ:'demo'])
>> session.transfer(ff, REL_SUCCESS);
>> }
>> ```
>> org.apache.nifi.processor.exception.FlowFileHandlingException:
>> FlowFile[0,54356692392022.mockFlowFile,131B] is not the most recent version
>> of this flow file within this session
>> 
>> Thanks
>> Sumanth

Re: nfii-integration-tests

[Joe Skora]

This sounds great.  Profile activation makes sense.  I like the test app
idea as well, perhaps we could eventually capture some data from that such
as CPU time, memory usage, architecture, etc. to better gather a set of
benchmarks and expectations for various components.

Would it make sense to also have a profile for each service dependency such
as AWS, Hadoop, Kafka, etc.; so that even where only some services are
available those tests could still be run?

On Mon, Dec 21, 2015 at 4:09 PM, Tony Kurc  wrote:

> I was trying to look through projects that had tests like this.. Rather
> than the tests being part of the build, they could be standalone apps,
> maybe like the accumulo continuous ingest tests?
>
> Tony
> On Dec 21, 2015 4:00 PM, "Oleg Zhurakousky" 
> wrote:
>
> > Correct, and I think my point would be it depends on the individual test,
> > but in any event, let me take a first crack at it and then we can decide.
> >
> > > On Dec 21, 2015, at 3:46 PM, Joe Witt  wrote:
> > >
> > > i suspect we're all thinking 'how long will they run and if long let's
> > > support profile activation'?
> > >
> > > On Mon, Dec 21, 2015 at 3:34 PM, Oleg Zhurakousky
> > >  wrote:
> > >> Cool, I may need some help with maven, but I’ll push a PR when ready.
> > >> Also, I don’t see these unit tests any different then any other unit
> > tests. The only difference is that they will test functionality that
> > requires multiple modules (e.g., site-to-site)
> > >>
> > >> Oleg
> > >>> On Dec 21, 2015, at 3:28 PM, Joe Witt  wrote:
> > >>>
> > >>> profile activated i hope :-)
> > >>>
> > >>> Right under nifi seems fine to me.
> > >>>
> > >>> Thanks
> > >>> Joe
> > >>>
> > >>> On Mon, Dec 21, 2015 at 3:22 PM, Oleg Zhurakousky
> > >>>  wrote:
> >  Not on github yet. Basically another module right at the root of
> > nifi, hence it will be subject to global build, test etc.
> >  Oleg
> > 
> > > On Dec 21, 2015, at 3:12 PM, Tony Kurc  wrote:
> > >
> > > I certainly am interested in such a thing. How do you see this
> > fitting in
> > > the source tree/ build cycle?
> > > On Dec 21, 2015 3:07 PM, "Oleg Zhurakousky" <
> > ozhurakou...@hortonworks.com>
> > > wrote:
> > >
> > >> Guys
> > >>
> > >> I’ve created a module called nfii-integration-tests. The goal of
> > this
> > >> module is to facilitate unit testing of things that required
> > collaboration
> > >> between the modules (e.g., site-to-site) as well as discover
> > potential
> > >> improvements that could be made to the code base (e.g.,
> NIFI-1318).
> > >> It helps me quite a bit so I was wondering if there is any
> interest
> > in
> > >> adding such module to NiFi?
> > >>
> > >> Cheers
> > >> Oleg
> > 
> > >>>
> > >>
> > >
> >
> >
>

Re: Cluster Setup

[plj]

Thank you very much.  That solved the problem.  I changed from the default
blank value to the name of the machine on the NCM but I still got errors. 
When I filled in the value on the node machine it started working.




--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Cluster-Setup-tp5853p5911.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Input Forbidden Requirement

[Joe Witt]

I've updated the migration guidance to better highlight this change:
https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance

It is important to note that GetFile has never been driven by input
flow files.  The desire for that totally makes sense and that is what
the ListFile/FetchFile pattern supports which is also part of the
0.4.0 release.  I believe this handles your case with the elegance
you're looking for.

Thanks
Joe

On Tue, Dec 22, 2015 at 2:00 PM, Ian Moran  wrote:
> To toss in another instance where this change can act against valid
> use-cases, consider any instance where you might want to use the Expression
> Language to cause one of these 'source' processors to not only run on a
> 'trigger', but also run more dynamically. Previously, you could potentially
> use ExtractText to set up Flowfile attributes you could then reference in
> GetFile's Input Directory property, allowing you to specifically target
> certain sub-directories for example. Without the ability to route
> attribute-laden Flowfiles to GetFile, however, you're limited to only using
> Environment variables with the expression language. Still useful in some
> instances, but certainly not as robust.
>
> I'm just thinking 'out loud' here, but instead of outright disallowing
> incoming connections to processors that are output only, would it be
> possible to give some visual indication to the user that the *content* of
> the Flowfile will be ignored, and most likely overwritten, but still allow
> them to utilize the connection to trigger the processor to run (and
> possibly deliver attributes for the Expression Language's use)?
>
> On Tue, Dec 22, 2015 at 11:53 AM, Ricky Saltzer  wrote:
>
>> Aha, that makes sense. Thanks for the explanation! I do agree that it could
>> be useful to have control over when those types of processors execute.
>>
>
>
>
> --
>
> *Ian Moran | **Associate Software Developer** | Saggezza*
>
>
>
> Email: *ian.mo...@saggezza.com* | Office: 312-267-2929
>
> @saggezza_inc  | LinkedIn
>  | www.saggezza.com