Re: SNMP Processors

[Pierre Villard]

Yes I will also consider a listener and a sender for SNMP traps.

2016-02-18 22:17 GMT+01:00 Simon Ball :

> Have you considered a trap listener, that would make a nice addition to
> the bundle.
>
> Simon
>
> -
> Simon Elliston Ball
> Product Solutions Architect
> Hortonworks - Powering the future of data
>
>
> On 18 Feb 2016, at 20:29, Pierre Villard  > wrote:
>
> I created a JIRA (https://issues.apache.org/jira/browse/NIFI-1537). Will
> work on it soon.
>
> 2016-02-18 21:07 GMT+01:00 Pierre Villard  >:
>
> Hi Joe,
>
> I do see use cases where interactions with SNMP could be useful. I
> preferred to ask because, to be honest, I am going to join the French team
> at Hortonworks in about 2 months, and I am eager to collaborate in a useful
> manner. Well... at least I'll do my best! So if there are improvements I
> may be able to implement, I'd be happy to spend some of my spare time on
> it!
>
> Pierre
>
> 2016-02-18 19:56 GMT+01:00 Joe Witt  joe.w...@gmail.com>>:
>
> Pierre,
>
> In my view the best and first test of interest is your own.  If you
> see that you could use it then there is a good shot others will as
> well.  I think interaction with SNMP makes sense and look forward to
> checking it out if you do find time to contribute that.
>
> Thanks
> Joe
>
> On Thu, Feb 18, 2016 at 1:29 PM, Pierre Villard
> mailto:pierre.villard...@gmail.com>> wrote:
> Hi,
>
> Would that be of any interest to have processors for SNMP exchanges
> using
> snmp4j?
>
> I was thinking about something like:
>
> GetSNMP
> possibility to do a SNMP get or a SNMP walk, the flow file would not
> have
> any content, just attributes with key = requested oid and value =
> requested
> value.
>
> SetSNMP
> do a SNMP set according to flow file / processor properties. There are
> multiple options there, don't know what sounds best.
>
> If you think it could be useful, I will have a look developing that.
>
> Pierre
>
>
>
>

Re: [DISCUSS] NiFi 0.5.1 release

[Joe Witt]

Ok so looks like the major players for the 0.5.1 release are in.
Today during some testing it was discovered that there can be issues
with multiple HDFS processors with differing configurations and
yesterday on StackOverflow it was reported that there are some issues
talking to Kafka but there is a viable workaround for now.  I
personally feel like what we have for an 0.5.1 is good right now
without those two JIRAs and that we could do an 0.5.2 if those get
sorted soon or they can go in 0.6.0 which if we stick to the
previously discussed idea would be mid-March.

What do ya'll think?

If we did a kick-off of RC say late Sunday (assuming RM is on board
too of course) we'd be looking at a midweek release for 0.5.1

Thanks
Joe

On Wed, Feb 17, 2016 at 9:13 PM, Joe Witt  wrote:
> +1
>
> On Wed, Feb 17, 2016 at 10:12 PM, Tony Kurc  wrote:
>> All,
>> Just so we're clear, my expectations is that the fixes we need above will
>> go into master (0.6.0-SNAPSHOT). I (or the contributor) will attempt to
>> also apply those fixes to a branch I made off of nifi-0.5.0, called
>> "support/nifi-0.5.x", and when done we can test and when satisfied, start
>> the 0.5.1 release process.
>>
>>
>> On Wed, Feb 17, 2016 at 8:28 PM, Tony Kurc  wrote:
>>
>>> I lieu of a decision on a git branching strategy, does anyone object to me
>>> naming a branch "support/0.5.x" so I can start pulling together 0.5.1?
>>>
>>> On Wed, Feb 17, 2016 at 8:17 PM, Joe Witt  wrote:
>>>
 Team,

 First, congrats on getting 0.5.0 out the door.  Very nice release with
 excellent new features, enhancements, and bug fixes with involvement
 of many new contributors.

 The effort toward 0.6.0 is well underway and if we are shooting for
 our original target would still arrive around mid march-ish.  Seems
 reasonable given progress so far.

 That said, I'd like to propose we go ahead and put out an 0.5.1 as
 soon as the patches are addressed.  The finding that Lars helped
 expose and that Mark Payne is now working  [1] in my view warrants a
 release by itself as it is data loss related.  Also, we can address
 the work Matt Gilman is doing to ensure properly authorized users can
 access resources they're being blocked by [2] and the license/notice
 findings Sean discovered during the last release [3].  There are a
 couple odd/ends in the list as well [4].  Purely a bug fix release as
 spec'd out in release notes [5].

 I checked with Tony and he is happy to continue performing RM tasks on
 the 0.5.x line.

 [1] https://issues.apache.org/jira/browse/NIFI-1527
 [2] https://issues.apache.org/jira/browse/NIFI-1497
 [3] https://issues.apache.org/jira/browse/NIFI-1520
 [4] https://s.apache.org/nifi-0.5.1-candidate
 [5] https://cwiki.apache.org/confluence/display/NIFI/Release+Notes

 Thanks
 Joe

>>>
>>>

Re: [DISCUSS] NiFi 0.5.1 release

[Brandon DeVries]

+1 for getting 0.5.1 out the door sooner rather than later.  Like you
said... if the other tickets get sorted out in a week or so, we can do
0.5.2.  Otherwise, 0.6.0 isn't that far off.  But a fix involving data loss
is worth doing quickly.

Brandon

On Fri, Feb 19, 2016 at 4:18 PM Joe Witt  wrote:

> Ok so looks like the major players for the 0.5.1 release are in.
> Today during some testing it was discovered that there can be issues
> with multiple HDFS processors with differing configurations and
> yesterday on StackOverflow it was reported that there are some issues
> talking to Kafka but there is a viable workaround for now.  I
> personally feel like what we have for an 0.5.1 is good right now
> without those two JIRAs and that we could do an 0.5.2 if those get
> sorted soon or they can go in 0.6.0 which if we stick to the
> previously discussed idea would be mid-March.
>
> What do ya'll think?
>
> If we did a kick-off of RC say late Sunday (assuming RM is on board
> too of course) we'd be looking at a midweek release for 0.5.1
>
> Thanks
> Joe
>
> On Wed, Feb 17, 2016 at 9:13 PM, Joe Witt  wrote:
> > +1
> >
> > On Wed, Feb 17, 2016 at 10:12 PM, Tony Kurc  wrote:
> >> All,
> >> Just so we're clear, my expectations is that the fixes we need above
> will
> >> go into master (0.6.0-SNAPSHOT). I (or the contributor) will attempt to
> >> also apply those fixes to a branch I made off of nifi-0.5.0, called
> >> "support/nifi-0.5.x", and when done we can test and when satisfied,
> start
> >> the 0.5.1 release process.
> >>
> >>
> >> On Wed, Feb 17, 2016 at 8:28 PM, Tony Kurc  wrote:
> >>
> >>> I lieu of a decision on a git branching strategy, does anyone object
> to me
> >>> naming a branch "support/0.5.x" so I can start pulling together 0.5.1?
> >>>
> >>> On Wed, Feb 17, 2016 at 8:17 PM, Joe Witt  wrote:
> >>>
>  Team,
> 
>  First, congrats on getting 0.5.0 out the door.  Very nice release with
>  excellent new features, enhancements, and bug fixes with involvement
>  of many new contributors.
> 
>  The effort toward 0.6.0 is well underway and if we are shooting for
>  our original target would still arrive around mid march-ish.  Seems
>  reasonable given progress so far.
> 
>  That said, I'd like to propose we go ahead and put out an 0.5.1 as
>  soon as the patches are addressed.  The finding that Lars helped
>  expose and that Mark Payne is now working  [1] in my view warrants a
>  release by itself as it is data loss related.  Also, we can address
>  the work Matt Gilman is doing to ensure properly authorized users can
>  access resources they're being blocked by [2] and the license/notice
>  findings Sean discovered during the last release [3].  There are a
>  couple odd/ends in the list as well [4].  Purely a bug fix release as
>  spec'd out in release notes [5].
> 
>  I checked with Tony and he is happy to continue performing RM tasks on
>  the 0.5.x line.
> 
>  [1] https://issues.apache.org/jira/browse/NIFI-1527
>  [2] https://issues.apache.org/jira/browse/NIFI-1497
>  [3] https://issues.apache.org/jira/browse/NIFI-1520
>  [4] https://s.apache.org/nifi-0.5.1-candidate
>  [5] https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
> 
>  Thanks
>  Joe
> 
> >>>
> >>>
>

[GitHub] nifi pull request: NIFI-1529 Forcing hadoop-libraries-nar to versi...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/236


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] NiFi 0.5.1 release

[Oleg Zhurakousky]

So I am working in Kafka and while its a bug it’s not easy to fix with the 
current state of things (see more details here 
https://issues.apache.org/jira/browse/NIFI-1534)
So, there need to be some refactoring within NiFi core to address it right, so 
I’ve just changed the target to be 0.6.0.

For the time being, we know about Kafka issue and we know that it’s not an 
issue unless Run-duration > 0. So until 0.6 we should simply recommend to not 
use Run-duartion with PutKafka.

Cheers
Oleg

On Feb 19, 2016, at 4:18 PM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:

Ok so looks like the major players for the 0.5.1 release are in.
Today during some testing it was discovered that there can be issues
with multiple HDFS processors with differing configurations and
yesterday on StackOverflow it was reported that there are some issues
talking to Kafka but there is a viable workaround for now.  I
personally feel like what we have for an 0.5.1 is good right now
without those two JIRAs and that we could do an 0.5.2 if those get
sorted soon or they can go in 0.6.0 which if we stick to the
previously discussed idea would be mid-March.

What do ya'll think?

If we did a kick-off of RC say late Sunday (assuming RM is on board
too of course) we'd be looking at a midweek release for 0.5.1

Thanks
Joe

On Wed, Feb 17, 2016 at 9:13 PM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:
+1

On Wed, Feb 17, 2016 at 10:12 PM, Tony Kurc 
mailto:trk...@gmail.com>> wrote:
All,
Just so we're clear, my expectations is that the fixes we need above will
go into master (0.6.0-SNAPSHOT). I (or the contributor) will attempt to
also apply those fixes to a branch I made off of nifi-0.5.0, called
"support/nifi-0.5.x", and when done we can test and when satisfied, start
the 0.5.1 release process.


On Wed, Feb 17, 2016 at 8:28 PM, Tony Kurc 
mailto:trk...@gmail.com>> wrote:

I lieu of a decision on a git branching strategy, does anyone object to me
naming a branch "support/0.5.x" so I can start pulling together 0.5.1?

On Wed, Feb 17, 2016 at 8:17 PM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:

Team,

First, congrats on getting 0.5.0 out the door.  Very nice release with
excellent new features, enhancements, and bug fixes with involvement
of many new contributors.

The effort toward 0.6.0 is well underway and if we are shooting for
our original target would still arrive around mid march-ish.  Seems
reasonable given progress so far.

That said, I'd like to propose we go ahead and put out an 0.5.1 as
soon as the patches are addressed.  The finding that Lars helped
expose and that Mark Payne is now working  [1] in my view warrants a
release by itself as it is data loss related.  Also, we can address
the work Matt Gilman is doing to ensure properly authorized users can
access resources they're being blocked by [2] and the license/notice
findings Sean discovered during the last release [3].  There are a
couple odd/ends in the list as well [4].  Purely a bug fix release as
spec'd out in release notes [5].

I checked with Tony and he is happy to continue performing RM tasks on
the 0.5.x line.

[1] https://issues.apache.org/jira/browse/NIFI-1527
[2] https://issues.apache.org/jira/browse/NIFI-1497
[3] https://issues.apache.org/jira/browse/NIFI-1520
[4] https://s.apache.org/nifi-0.5.1-candidate
[5] https://cwiki.apache.org/confluence/display/NIFI/Release+Notes

Thanks
Joe

Re: [DISCUSS] NiFi 0.5.1 release

[Tony Kurc]

sunday works for me.

On Fri, Feb 19, 2016 at 4:18 PM, Joe Witt  wrote:

> Ok so looks like the major players for the 0.5.1 release are in.
> Today during some testing it was discovered that there can be issues
> with multiple HDFS processors with differing configurations and
> yesterday on StackOverflow it was reported that there are some issues
> talking to Kafka but there is a viable workaround for now.  I
> personally feel like what we have for an 0.5.1 is good right now
> without those two JIRAs and that we could do an 0.5.2 if those get
> sorted soon or they can go in 0.6.0 which if we stick to the
> previously discussed idea would be mid-March.
>
> What do ya'll think?
>
> If we did a kick-off of RC say late Sunday (assuming RM is on board
> too of course) we'd be looking at a midweek release for 0.5.1
>
> Thanks
> Joe
>
> On Wed, Feb 17, 2016 at 9:13 PM, Joe Witt  wrote:
> > +1
> >
> > On Wed, Feb 17, 2016 at 10:12 PM, Tony Kurc  wrote:
> >> All,
> >> Just so we're clear, my expectations is that the fixes we need above
> will
> >> go into master (0.6.0-SNAPSHOT). I (or the contributor) will attempt to
> >> also apply those fixes to a branch I made off of nifi-0.5.0, called
> >> "support/nifi-0.5.x", and when done we can test and when satisfied,
> start
> >> the 0.5.1 release process.
> >>
> >>
> >> On Wed, Feb 17, 2016 at 8:28 PM, Tony Kurc  wrote:
> >>
> >>> I lieu of a decision on a git branching strategy, does anyone object
> to me
> >>> naming a branch "support/0.5.x" so I can start pulling together 0.5.1?
> >>>
> >>> On Wed, Feb 17, 2016 at 8:17 PM, Joe Witt  wrote:
> >>>
>  Team,
> 
>  First, congrats on getting 0.5.0 out the door.  Very nice release with
>  excellent new features, enhancements, and bug fixes with involvement
>  of many new contributors.
> 
>  The effort toward 0.6.0 is well underway and if we are shooting for
>  our original target would still arrive around mid march-ish.  Seems
>  reasonable given progress so far.
> 
>  That said, I'd like to propose we go ahead and put out an 0.5.1 as
>  soon as the patches are addressed.  The finding that Lars helped
>  expose and that Mark Payne is now working  [1] in my view warrants a
>  release by itself as it is data loss related.  Also, we can address
>  the work Matt Gilman is doing to ensure properly authorized users can
>  access resources they're being blocked by [2] and the license/notice
>  findings Sean discovered during the last release [3].  There are a
>  couple odd/ends in the list as well [4].  Purely a bug fix release as
>  spec'd out in release notes [5].
> 
>  I checked with Tony and he is happy to continue performing RM tasks on
>  the 0.5.x line.
> 
>  [1] https://issues.apache.org/jira/browse/NIFI-1527
>  [2] https://issues.apache.org/jira/browse/NIFI-1497
>  [3] https://issues.apache.org/jira/browse/NIFI-1520
>  [4] https://s.apache.org/nifi-0.5.1-candidate
>  [5] https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
> 
>  Thanks
>  Joe
> 
> >>>
> >>>
>

[GitHub] nifi pull request: NIFI-840: Create ListS3 processor

[adamonduty]

GitHub user adamonduty opened a pull request:

https://github.com/apache/nifi/pull/238

NIFI-840: Create ListS3 processor

This processor implements an object listing capability for S3. I tried to 
model it after ListHDFS, but I wasn't able to test the parts that persist 
state, so I don't know if it works correctly when the primary node in a cluster 
changes.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/adamonduty/nifi NIFI-840

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/238.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #238


commit 6dacb76016b11839b475803bf139bea15f17b806
Author: Adam Lamar 
Date:   2016-02-19T06:13:24Z

NIFI-840: Create ListS3 processor




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---