Dealing with cluster errors

[Joe Gresock]

We have a 7-node cluster and we currently use the embedded zookeepers on 3
of the nodes.  I've noticed that when we have a high volume in our flow
(which is causing the CPU to be hit pretty hard), I have a really hard time
getting the console page to come up, as it cycles through the following
error messages when I relolad the page:


   - An unexpected error has occurred.  Please check the logs.  (there is
   never any error in the logs for this one)
   - Could not replicate request to  because the node is not
   connected   (this is never the current host I'm trying to hit, which makes
   the error text feel a bit irrelevant to the user.  i.e., "I wasn't trying
   to replicate a request to that node, I just want to load the console on
   this node")
   - An error occurred communicating with the application core.  Please
   check the logs and fix any configuration issues before restarting.  (Again,
   can't find any errors in nifi-app.log or nifi-user.log)

I can go about a half-hour reloading the page before it comes up once, and
then I can only get maybe one action in before it auto-refreshes and shows
me one of the above error messages again.

My first thought was that using some external zookeeper servers would
improve this, but that's just a hunch.  Has anyone encountered this
behavior with high data volume?
Joe

-- 
I know what it is to be in need, and I know what it is to have plenty.  I
have learned the secret of being content in any and every situation,
whether well fed or hungry, whether living in plenty or in want.  I can do
all this through him who gives me strength.*-Philippians 4:12-13*

Re: Dealing with cluster errors

[Joe Gresock]

I should add that the flows on the individual nodes appear to be processing
the data just fine, and the solution I've found so far is to just wait for
the data to subside, after which point the console comes up successfully.
So, no complaint on the durability of the underlying data flows.  It's just
problematic that I can't reliably make changes to the flow during high
traffic periods.

On Fri, Feb 10, 2017 at 12:00 PM, Joe Gresock  wrote:

> We have a 7-node cluster and we currently use the embedded zookeepers on 3
> of the nodes.  I've noticed that when we have a high volume in our flow
> (which is causing the CPU to be hit pretty hard), I have a really hard time
> getting the console page to come up, as it cycles through the following
> error messages when I relolad the page:
>
>
>- An unexpected error has occurred.  Please check the logs.  (there is
>never any error in the logs for this one)
>- Could not replicate request to  because the node is not
>connected   (this is never the current host I'm trying to hit, which makes
>the error text feel a bit irrelevant to the user.  i.e., "I wasn't trying
>to replicate a request to that node, I just want to load the console on
>this node")
>- An error occurred communicating with the application core.  Please
>check the logs and fix any configuration issues before restarting.  (Again,
>can't find any errors in nifi-app.log or nifi-user.log)
>
> I can go about a half-hour reloading the page before it comes up once, and
> then I can only get maybe one action in before it auto-refreshes and shows
> me one of the above error messages again.
>
> My first thought was that using some external zookeeper servers would
> improve this, but that's just a hunch.  Has anyone encountered this
> behavior with high data volume?
> Joe
>
> --
> I know what it is to be in need, and I know what it is to have plenty.  I
> have learned the secret of being content in any and every situation,
> whether well fed or hungry, whether living in plenty or in want.  I can
> do all this through him who gives me strength.*-Philippians 4:12-13*
>



-- 
I know what it is to be in need, and I know what it is to have plenty.  I
have learned the secret of being content in any and every situation,
whether well fed or hungry, whether living in plenty or in want.  I can do
all this through him who gives me strength.*-Philippians 4:12-13*

Re: Controls the order in which processors are executed

[Aldrin Piri]

Hi Petter,

It seems the image did not make it through to the list.  Could you please
upload it elsewhere and then provide a link?

Are you looking to have a specific sequence of actions for your components?

On Fri, Feb 10, 2017 at 1:24 AM, wangj...@weiresearch.com <
wangj...@weiresearch.com> wrote:

> Nifi 1.1.1
> I recently created three processors, as shown below.
>
> I want all selected, the first implementation of the
> spiderProcessor, and then the implementation of b extractTableProcessor,
> the final implementation of ChineseProcessor. In short, I would like to
> have a processor on the order of the implementation of the controller, you
> can help me Mody, very grateful.
>
> *tank you for much*
> *petter wang*
> *2017-02-10*
>
>

Re: Build failure on Mac OS X with DS_STORE files

[Otto Fowler]

OK - I can build with the latest JDK ( except for the DS_Store issue.  So
the problem is that
the getting started page should not just say Java 8, is should have some
version of the JDK that will actually build.



On February 9, 2017 at 19:34:31, Otto Fowler (ottobackwa...@gmail.com)
wrote:

I am using 1.8.0_31


I have been able to get a complete good build, but I had to make a few
changes.

On February 9, 2017 at 18:34:48, Koji Kawamura (ijokaruma...@gmail.com)
wrote:

Hi Otto,

Which version of Java are you using?
I remember early version of Java 8 fails to pass the test. Would you
try to update JDK version and build it again?

Thanks,
Koji

On Fri, Feb 10, 2017 at 3:43 AM, Otto Fowler 
wrote:
> OK, that is good. There very well could be something ‘special’ about what
> I am seeing.
> I am fixing things as I find them. The things that are not working make
> sense to me, in other words I’m not sure how they are not broken for
> everyone.
>
> Maybe if I get to the end of it, I’ll post what the patch *would* be?
>
>
> On February 9, 2017 at 11:11:55, Joe Skora (jsk...@gmail.com) wrote:
>
> Otto,
>
> I regularly build on a Mac without problems, and I believe a lot of
> contributors do as well.
>
> I haven't run into the .DS_Store issues with NiFi, probably because I
> rarely use Finder to access my build folders.
>
> I don't recall any issues with ScriptingProcessor, but it's been a week or
> more since I built on the Mac, I can check it tonight.
>
> Regards,
> Joe
>
> On Thu, Feb 9, 2017 at 10:59 AM, Otto Fowler 
> wrote:
>
>> So,
>>
>> I could have a pr that fixes that problem, but I’m seeing new problems
>> now. I can submit the pr then keep looking at the other problems (
> meaning
>> I can submit a pr without having a working complete build, just fixing
> that
>> test ), but I’m not sure how you all handle things like this.
>>
>> I have to ask, does anyone working on NiFi use a mac? The next problems I
>> have are not with .DS_Store files or anything ‘mac centric’, they are
> with
>> Nashorn Java script types in the ScriptingProcessor tests…..
>>
>> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokaruma...@gmail.com)
>> wrote:
>>
>> Thanks! Please ping me when the PR is ready.
>>
>> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler 
>> wrote:
>> > Sure - I see what you mean, that is a much better approach.
>> > I will certainly do that.
>> >
>> >
>> >
>> > On February 9, 2017 at 09:02:05, Koji Kawamura (ijokaruma...@gmail.com)
>> > wrote:
>> >
>> > Hi Otto,
>> >
>> > Thanks for reporting this. I personally haven't encountered this
>> > issue, but as described here [1], when I opened the directory that the
>> > test uses by Mac Finder application, and changed view as icon and move
>> > the icon position, then a .DS_Store file was created.
>> >
>> > I agree with your workaround and I think we should resolve the issue.
>> > By looking at the usage of that method, such as DBCPConnectionPool, or
>> > JoltTransformJSON, those uses file name filter like this:
>> >
>> > (dir, name) -> name != null && name.endsWith(".jar")
>> >
>> > While filtering out specific .DS_Store works, targeting only name
>> > ending with .jar looks more generic work around.
>> >
>> > Would you mind open a JIRA and send a PR? I'd happy to review!
>> >
>> > Thanks,
>> > Koji
>> >
>> > On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler 
>> wrote:
>> >> If it turns out that this *is* something you would like addressed, I
> can
>> >> do
>> >> the jira and the PR
>> >>
>> >>
>> >> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwa...@gmail.com)
>> >> wrote:
>> >>
>> >> @Test
>> >> public void testGetURLsForClasspathWithDirectory() throws
>> >> MalformedURLException {
>> >> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> >> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> >> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> >> assertEquals(2, urls.length);
>> >> }
>> >>
>> >>
>> >> resolves the issue, and I am able to build everything.
>> >>
>> >>
>> >> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwa...@gmail.com)
>> >> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I’m trying to build master on Mac OS X, following the instructions
> from
>> >> the
>> >> site linked in the README.md.
>> >>
>> >> My build is failing because the unit test:
>> >> testGetURLsForClasspathWithDirectory
>> >> in TestClassLoaderUtils.
>> >>
>> >> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> >> because the DS_STORE is detected and has an url built and returned for
>> it.
>> >>
>> >> The test does not pass in a FileNamesFilter, which could be used to
>> filter
>> >> these files out I suppose.
>> >>
>> >> I am wondering if anyone is building successfully on Mac OS X?
>>

Re: Dealing with cluster errors

[Andrew Grande]

Joe,

External ZK quorum would be my first move. And make sure those boxes have
fast disks and no heavy load from other processes.

Andrew

On Fri, Feb 10, 2017, 7:23 AM Joe Gresock  wrote:

> I should add that the flows on the individual nodes appear to be processing
> the data just fine, and the solution I've found so far is to just wait for
> the data to subside, after which point the console comes up successfully.
> So, no complaint on the durability of the underlying data flows.  It's just
> problematic that I can't reliably make changes to the flow during high
> traffic periods.
>
> On Fri, Feb 10, 2017 at 12:00 PM, Joe Gresock  wrote:
>
> > We have a 7-node cluster and we currently use the embedded zookeepers on
> 3
> > of the nodes.  I've noticed that when we have a high volume in our flow
> > (which is causing the CPU to be hit pretty hard), I have a really hard
> time
> > getting the console page to come up, as it cycles through the following
> > error messages when I relolad the page:
> >
> >
> >- An unexpected error has occurred.  Please check the logs.  (there is
> >never any error in the logs for this one)
> >- Could not replicate request to  because the node is not
> >connected   (this is never the current host I'm trying to hit, which
> makes
> >the error text feel a bit irrelevant to the user.  i.e., "I wasn't
> trying
> >to replicate a request to that node, I just want to load the console
> on
> >this node")
> >- An error occurred communicating with the application core.  Please
> >check the logs and fix any configuration issues before restarting.
> (Again,
> >can't find any errors in nifi-app.log or nifi-user.log)
> >
> > I can go about a half-hour reloading the page before it comes up once,
> and
> > then I can only get maybe one action in before it auto-refreshes and
> shows
> > me one of the above error messages again.
> >
> > My first thought was that using some external zookeeper servers would
> > improve this, but that's just a hunch.  Has anyone encountered this
> > behavior with high data volume?
> > Joe
> >
> > --
> > I know what it is to be in need, and I know what it is to have plenty.  I
> > have learned the secret of being content in any and every situation,
> > whether well fed or hungry, whether living in plenty or in want.  I can
> > do all this through him who gives me strength.*-Philippians 4:12-13*
> >
>
>
>
> --
> I know what it is to be in need, and I know what it is to have plenty.  I
> have learned the secret of being content in any and every situation,
> whether well fed or hungry, whether living in plenty or in want.  I can do
> all this through him who gives me strength.*-Philippians 4:12-13*
>

TLS Requirements for S2S for MiNiFi

[Marc]

Hello Everyone,
   I'm seeing build failures on the head of MiNiFi-CPP on my test platform
that lacks OpenSSL ( I have one with and one without ). I see that the
context is defined as a member of the Site2SitePeer [1]. Clearly the
Site2Site functionality works on Linux without OpenSSL, so I'm wondering if
the intent is to move to require TLSV1.2 for all comms. If not, I'll create
a ticket to abstract this functionality out appropriately. If this is a req
moving forward I'll ensure all of my test VMs have the aforementioned
libraries installed. To be clear the Readme shows OpenSSL as a requirement,
so I imagine this is simply a stepwise requirement.
   Thanks for any clarification.
   Best Regards,
   Marc Parisi

[1]
https://github.com/apache/nifi-minifi-cpp/blob/master/libminifi/include/Site2SitePeer.h

Re: Build failure on Mac OS X with DS_STORE files

[Otto Fowler]

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


On February 9, 2017 at 09:19:21, Koji Kawamura (ijokaruma...@gmail.com)
wrote:

Thanks! Please ping me when the PR is ready.

On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler 
wrote:
> Sure - I see what you mean, that is a much better approach.
> I will certainly do that.
>
>
>
> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokaruma...@gmail.com)
> wrote:
>
> Hi Otto,
>
> Thanks for reporting this. I personally haven't encountered this
> issue, but as described here [1], when I opened the directory that the
> test uses by Mac Finder application, and changed view as icon and move
> the icon position, then a .DS_Store file was created.
>
> I agree with your workaround and I think we should resolve the issue.
> By looking at the usage of that method, such as DBCPConnectionPool, or
> JoltTransformJSON, those uses file name filter like this:
>
> (dir, name) -> name != null && name.endsWith(".jar")
>
> While filtering out specific .DS_Store works, targeting only name
> ending with .jar looks more generic work around.
>
> Would you mind open a JIRA and send a PR? I'd happy to review!
>
> Thanks,
> Koji
>
> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler 
wrote:
>> If it turns out that this *is* something you would like addressed, I can
>> do
>> the jira and the PR
>>
>>
>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwa...@gmail.com)
>> wrote:
>>
>> @Test
>> public void testGetURLsForClasspathWithDirectory() throws
>> MalformedURLException {
>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>> assertEquals(2, urls.length);
>> }
>>
>>
>> resolves the issue, and I am able to build everything.
>>
>>
>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwa...@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> I’m trying to build master on Mac OS X, following the instructions from
>> the
>> site linked in the README.md.
>>
>> My build is failing because the unit test:
>> testGetURLsForClasspathWithDirectory
>> in TestClassLoaderUtils.
>>
>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>> because the DS_STORE is detected and has an url built and returned for
it.
>>
>> The test does not pass in a FileNamesFilter, which could be used to
filter
>> these files out I suppose.
>>
>> I am wondering if anyone is building successfully on Mac OS X?

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

[Bryan Bende]

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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Marc]

+1  non-binding -- but I think creating a sub project creates a demarcation
point that separates responsibilities in a way that makes sense.

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.mbo
> x/%3CCALo_M19euo2LLy0PVWmE70FzeLhQRcCtX6TC%3DqoiBVfn4zFQMA%4
> 0mail.gmail.com%3E
>

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

[Matt Gilman]

+1 binding

On Fri, Feb 10, 2017 at 11:47 AM, Marc  wrote:

> +1  non-binding -- but I think creating a sub project creates a demarcation
> point that separates responsibilities in a way that makes sense.
>
> 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.mbo
> > x/%3CCALo_M19euo2LLy0PVWmE70FzeLhQRcCtX6TC%3DqoiBVfn4zFQMA%4
> > 0mail.gmail.com%3E
> >
>

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

[Matt Burgess]

+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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Oleg Zhurakousky]

+1 Here as well. We desperately need it. 

> On Feb 10, 2017, at 12:11 PM, Jeremy Dyer  wrote:
> 
> +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: [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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Michael Moser]

I am in favor of the concept but the name made me pause.  I did a Google
search of "apache registry" and found an existing Perl module called
Apache::Registry.  Should I be worried about potential naming confusion?

-- Mike


On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> +1 Here as well. We desperately need it.
>
> > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer  wrote:
> >
> > +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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Joe Percivall]

I 100% agree with Mike and was actually in the process of writing a very
similar response. Just having "Registry" as the name will mean the
trademark will be "Apache Registry" and I don't think that conveys the
specificity of the sub-project. I'd much prefer something like NiFi
Registry like the initial discussion had.


Joe

On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser  wrote:

> I am in favor of the concept but the name made me pause.  I did a Google
> search of "apache registry" and found an existing Perl module called
> Apache::Registry.  Should I be worried about potential naming confusion?
>
> -- Mike
>
>
> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
> > +1 Here as well. We desperately need it.
> >
> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer  wrote:
> > >
> > > +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
> > >>
> >
> >
>



-- 
*Joe Percivall*
linkedin.com/in/Percivall
e: jperciv...@apache.com

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

[Bryan Bende]

Well using MiNiFi as an example...

Website - "MiNiFi - A subproject of Apache NiFi"
Git - "nifi-minifi.git"
JIRA - "Apache NiFi MiNiFi"

For Registry I was thinking...

Website - "Registry - A subproject of Apache NiFi"
Git - "nifi-registry.git"
JIRA "Apache NiFi Registry"

So I didn't think there was a case where it would be referred to as
only "Apache Registry", but if sub-project names are trademarked on
their own then I do agree we would likely have to call it "NiFi
Registry".


On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall  wrote:
> I 100% agree with Mike and was actually in the process of writing a very
> similar response. Just having "Registry" as the name will mean the
> trademark will be "Apache Registry" and I don't think that conveys the
> specificity of the sub-project. I'd much prefer something like NiFi
> Registry like the initial discussion had.
>
>
> Joe
>
> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser  wrote:
>
>> I am in favor of the concept but the name made me pause.  I did a Google
>> search of "apache registry" and found an existing Perl module called
>> Apache::Registry.  Should I be worried about potential naming confusion?
>>
>> -- Mike
>>
>>
>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
>> ozhurakou...@hortonworks.com> wrote:
>>
>> > +1 Here as well. We desperately need it.
>> >
>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer  wrote:
>> > >
>> > > +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
>> > >>
>> >
>> >
>>
>
>
>
> --
> *Joe Percivall*
> linkedin.com/in/Percivall
> e: jperciv...@apache.com

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

[Joe Witt]

The name 'registry' is insufficient but we're not creating 'Apache
Registry'.  We're creating a subproject of 'Apache NiFi' which is a
TLP of the ASF.  This subproject, just like 'MiNiFi' would properly be
referred to as 'Registry: a subproject of Apache NiFi' or 'Apache NiFi
Registry'.  Apache NiFi Registry works out quite well to explain both
what it is an to be consistent with the marks.  See here for an
example of this guidance from ASF naming/marks guidance [1].

I view this vote as actually being about the community decision to
create this subproject with the stated goals and in that perspective I
am a strong +1.  I'm open to alternative names though I do think
"Apache NiFi Registry" is nice and descriptive.

[1] https://www.apache.org/dev/project-names.html

Thanks
Joe

On Fri, Feb 10, 2017 at 12:32 PM, Bryan Bende  wrote:
> Well using MiNiFi as an example...
>
> Website - "MiNiFi - A subproject of Apache NiFi"
> Git - "nifi-minifi.git"
> JIRA - "Apache NiFi MiNiFi"
>
> For Registry I was thinking...
>
> Website - "Registry - A subproject of Apache NiFi"
> Git - "nifi-registry.git"
> JIRA "Apache NiFi Registry"
>
> So I didn't think there was a case where it would be referred to as
> only "Apache Registry", but if sub-project names are trademarked on
> their own then I do agree we would likely have to call it "NiFi
> Registry".
>
>
> On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall  wrote:
>> I 100% agree with Mike and was actually in the process of writing a very
>> similar response. Just having "Registry" as the name will mean the
>> trademark will be "Apache Registry" and I don't think that conveys the
>> specificity of the sub-project. I'd much prefer something like NiFi
>> Registry like the initial discussion had.
>>
>>
>> Joe
>>
>> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser  wrote:
>>
>>> I am in favor of the concept but the name made me pause.  I did a Google
>>> search of "apache registry" and found an existing Perl module called
>>> Apache::Registry.  Should I be worried about potential naming confusion?
>>>
>>> -- Mike
>>>
>>>
>>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
>>> ozhurakou...@hortonworks.com> wrote:
>>>
>>> > +1 Here as well. We desperately need it.
>>> >
>>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer  wrote:
>>> > >
>>> > > +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
>>> > >>
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> *Joe Percivall*
>> linkedin.com/in/Percivall
>> e: jperciv...@apache.com

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

[Pierre Villard]

+1 as well, that will be a very important piece of the ecosystem and
looking forward its development!

2017-02-10 18:47 GMT+01:00 Joe Witt :

> The name 'registry' is insufficient but we're not creating 'Apache
> Registry'.  We're creating a subproject of 'Apache NiFi' which is a
> TLP of the ASF.  This subproject, just like 'MiNiFi' would properly be
> referred to as 'Registry: a subproject of Apache NiFi' or 'Apache NiFi
> Registry'.  Apache NiFi Registry works out quite well to explain both
> what it is an to be consistent with the marks.  See here for an
> example of this guidance from ASF naming/marks guidance [1].
>
> I view this vote as actually being about the community decision to
> create this subproject with the stated goals and in that perspective I
> am a strong +1.  I'm open to alternative names though I do think
> "Apache NiFi Registry" is nice and descriptive.
>
> [1] https://www.apache.org/dev/project-names.html
>
> Thanks
> Joe
>
> On Fri, Feb 10, 2017 at 12:32 PM, Bryan Bende  wrote:
> > Well using MiNiFi as an example...
> >
> > Website - "MiNiFi - A subproject of Apache NiFi"
> > Git - "nifi-minifi.git"
> > JIRA - "Apache NiFi MiNiFi"
> >
> > For Registry I was thinking...
> >
> > Website - "Registry - A subproject of Apache NiFi"
> > Git - "nifi-registry.git"
> > JIRA "Apache NiFi Registry"
> >
> > So I didn't think there was a case where it would be referred to as
> > only "Apache Registry", but if sub-project names are trademarked on
> > their own then I do agree we would likely have to call it "NiFi
> > Registry".
> >
> >
> > On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall 
> wrote:
> >> I 100% agree with Mike and was actually in the process of writing a very
> >> similar response. Just having "Registry" as the name will mean the
> >> trademark will be "Apache Registry" and I don't think that conveys the
> >> specificity of the sub-project. I'd much prefer something like NiFi
> >> Registry like the initial discussion had.
> >>
> >>
> >> Joe
> >>
> >> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser 
> wrote:
> >>
> >>> I am in favor of the concept but the name made me pause.  I did a
> Google
> >>> search of "apache registry" and found an existing Perl module called
> >>> Apache::Registry.  Should I be worried about potential naming
> confusion?
> >>>
> >>> -- Mike
> >>>
> >>>
> >>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
> >>> ozhurakou...@hortonworks.com> wrote:
> >>>
> >>> > +1 Here as well. We desperately need it.
> >>> >
> >>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer 
> wrote:
> >>> > >
> >>> > > +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 <
> mattyb...@apache.org>
> >>> > 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_M19euo2LLy0PVWmE70FzeLhQRcCtX6
> TC%3DqoiBVfn4zFQMA%40mail.
> >>> > >> gmail.com%3E
> >>> > >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> *Joe Percivall*
> >> linkedin.com/in/Percivall
> >> e: jperciv...@apache.com
>

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

[Joe Percivall]

Thanks for the clarification Joe and Bryan, and we appear to be on the same
page that "Apache NiFi Registry" is how it would be referred to.

With that cleared up, I am a +1.

Joe

On Fri, Feb 10, 2017 at 1:01 PM, Pierre Villard  wrote:

> +1 as well, that will be a very important piece of the ecosystem and
> looking forward its development!
>
> 2017-02-10 18:47 GMT+01:00 Joe Witt :
>
> > The name 'registry' is insufficient but we're not creating 'Apache
> > Registry'.  We're creating a subproject of 'Apache NiFi' which is a
> > TLP of the ASF.  This subproject, just like 'MiNiFi' would properly be
> > referred to as 'Registry: a subproject of Apache NiFi' or 'Apache NiFi
> > Registry'.  Apache NiFi Registry works out quite well to explain both
> > what it is an to be consistent with the marks.  See here for an
> > example of this guidance from ASF naming/marks guidance [1].
> >
> > I view this vote as actually being about the community decision to
> > create this subproject with the stated goals and in that perspective I
> > am a strong +1.  I'm open to alternative names though I do think
> > "Apache NiFi Registry" is nice and descriptive.
> >
> > [1] https://www.apache.org/dev/project-names.html
> >
> > Thanks
> > Joe
> >
> > On Fri, Feb 10, 2017 at 12:32 PM, Bryan Bende  wrote:
> > > Well using MiNiFi as an example...
> > >
> > > Website - "MiNiFi - A subproject of Apache NiFi"
> > > Git - "nifi-minifi.git"
> > > JIRA - "Apache NiFi MiNiFi"
> > >
> > > For Registry I was thinking...
> > >
> > > Website - "Registry - A subproject of Apache NiFi"
> > > Git - "nifi-registry.git"
> > > JIRA "Apache NiFi Registry"
> > >
> > > So I didn't think there was a case where it would be referred to as
> > > only "Apache Registry", but if sub-project names are trademarked on
> > > their own then I do agree we would likely have to call it "NiFi
> > > Registry".
> > >
> > >
> > > On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall  >
> > wrote:
> > >> I 100% agree with Mike and was actually in the process of writing a
> very
> > >> similar response. Just having "Registry" as the name will mean the
> > >> trademark will be "Apache Registry" and I don't think that conveys the
> > >> specificity of the sub-project. I'd much prefer something like NiFi
> > >> Registry like the initial discussion had.
> > >>
> > >>
> > >> Joe
> > >>
> > >> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser 
> > wrote:
> > >>
> > >>> I am in favor of the concept but the name made me pause.  I did a
> > Google
> > >>> search of "apache registry" and found an existing Perl module called
> > >>> Apache::Registry.  Should I be worried about potential naming
> > confusion?
> > >>>
> > >>> -- Mike
> > >>>
> > >>>
> > >>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
> > >>> ozhurakou...@hortonworks.com> wrote:
> > >>>
> > >>> > +1 Here as well. We desperately need it.
> > >>> >
> > >>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer 
> > wrote:
> > >>> > >
> > >>> > > +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 <
> > mattyb...@apache.org>
> > >>> > 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_M19euo2LLy0PVWmE70FzeLhQRcCtX6
> > TC%3DqoiBVfn4zFQMA%40mail.
> > >>> > >> gmail.

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

[Michael Moser]

It definitely sounds like careful consideration was given to the name.

+1 (non-binding)


On Fri, Feb 10, 2017 at 1:03 PM, Joe Percivall 
wrote:

> Thanks for the clarification Joe and Bryan, and we appear to be on the same
> page that "Apache NiFi Registry" is how it would be referred to.
>
> With that cleared up, I am a +1.
>
> Joe
>
> On Fri, Feb 10, 2017 at 1:01 PM, Pierre Villard <
> pierre.villard...@gmail.com
> > wrote:
>
> > +1 as well, that will be a very important piece of the ecosystem and
> > looking forward its development!
> >
> > 2017-02-10 18:47 GMT+01:00 Joe Witt :
> >
> > > The name 'registry' is insufficient but we're not creating 'Apache
> > > Registry'.  We're creating a subproject of 'Apache NiFi' which is a
> > > TLP of the ASF.  This subproject, just like 'MiNiFi' would properly be
> > > referred to as 'Registry: a subproject of Apache NiFi' or 'Apache NiFi
> > > Registry'.  Apache NiFi Registry works out quite well to explain both
> > > what it is an to be consistent with the marks.  See here for an
> > > example of this guidance from ASF naming/marks guidance [1].
> > >
> > > I view this vote as actually being about the community decision to
> > > create this subproject with the stated goals and in that perspective I
> > > am a strong +1.  I'm open to alternative names though I do think
> > > "Apache NiFi Registry" is nice and descriptive.
> > >
> > > [1] https://www.apache.org/dev/project-names.html
> > >
> > > Thanks
> > > Joe
> > >
> > > On Fri, Feb 10, 2017 at 12:32 PM, Bryan Bende 
> wrote:
> > > > Well using MiNiFi as an example...
> > > >
> > > > Website - "MiNiFi - A subproject of Apache NiFi"
> > > > Git - "nifi-minifi.git"
> > > > JIRA - "Apache NiFi MiNiFi"
> > > >
> > > > For Registry I was thinking...
> > > >
> > > > Website - "Registry - A subproject of Apache NiFi"
> > > > Git - "nifi-registry.git"
> > > > JIRA "Apache NiFi Registry"
> > > >
> > > > So I didn't think there was a case where it would be referred to as
> > > > only "Apache Registry", but if sub-project names are trademarked on
> > > > their own then I do agree we would likely have to call it "NiFi
> > > > Registry".
> > > >
> > > >
> > > > On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall <
> jperciv...@apache.org
> > >
> > > wrote:
> > > >> I 100% agree with Mike and was actually in the process of writing a
> > very
> > > >> similar response. Just having "Registry" as the name will mean the
> > > >> trademark will be "Apache Registry" and I don't think that conveys
> the
> > > >> specificity of the sub-project. I'd much prefer something like NiFi
> > > >> Registry like the initial discussion had.
> > > >>
> > > >>
> > > >> Joe
> > > >>
> > > >> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser  >
> > > wrote:
> > > >>
> > > >>> I am in favor of the concept but the name made me pause.  I did a
> > > Google
> > > >>> search of "apache registry" and found an existing Perl module
> called
> > > >>> Apache::Registry.  Should I be worried about potential naming
> > > confusion?
> > > >>>
> > > >>> -- Mike
> > > >>>
> > > >>>
> > > >>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
> > > >>> ozhurakou...@hortonworks.com> wrote:
> > > >>>
> > > >>> > +1 Here as well. We desperately need it.
> > > >>> >
> > > >>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer 
> > > wrote:
> > > >>> > >
> > > >>> > > +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 <
> > > mattyb...@apache.org>
> > > >>> > wrote:
> > > >>> > >
> > > >>> > >> +1 binding
> > > >>> > >>
> > > >>> > >> On Fri, Feb 10, 2017 at 11:40 AM, Bryan Bende <
> bbe...@gmail.com
> > >
> > > >>> 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 ope

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

[Joe Gresock]

+1 (non-binding)

On Fri, Feb 10, 2017 at 6:26 PM, Michael Moser  wrote:

> It definitely sounds like careful consideration was given to the name.
>
> +1 (non-binding)
>
>
> On Fri, Feb 10, 2017 at 1:03 PM, Joe Percivall 
> wrote:
>
> > Thanks for the clarification Joe and Bryan, and we appear to be on the
> same
> > page that "Apache NiFi Registry" is how it would be referred to.
> >
> > With that cleared up, I am a +1.
> >
> > Joe
> >
> > On Fri, Feb 10, 2017 at 1:01 PM, Pierre Villard <
> > pierre.villard...@gmail.com
> > > wrote:
> >
> > > +1 as well, that will be a very important piece of the ecosystem and
> > > looking forward its development!
> > >
> > > 2017-02-10 18:47 GMT+01:00 Joe Witt :
> > >
> > > > The name 'registry' is insufficient but we're not creating 'Apache
> > > > Registry'.  We're creating a subproject of 'Apache NiFi' which is a
> > > > TLP of the ASF.  This subproject, just like 'MiNiFi' would properly
> be
> > > > referred to as 'Registry: a subproject of Apache NiFi' or 'Apache
> NiFi
> > > > Registry'.  Apache NiFi Registry works out quite well to explain both
> > > > what it is an to be consistent with the marks.  See here for an
> > > > example of this guidance from ASF naming/marks guidance [1].
> > > >
> > > > I view this vote as actually being about the community decision to
> > > > create this subproject with the stated goals and in that perspective
> I
> > > > am a strong +1.  I'm open to alternative names though I do think
> > > > "Apache NiFi Registry" is nice and descriptive.
> > > >
> > > > [1] https://www.apache.org/dev/project-names.html
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Fri, Feb 10, 2017 at 12:32 PM, Bryan Bende 
> > wrote:
> > > > > Well using MiNiFi as an example...
> > > > >
> > > > > Website - "MiNiFi - A subproject of Apache NiFi"
> > > > > Git - "nifi-minifi.git"
> > > > > JIRA - "Apache NiFi MiNiFi"
> > > > >
> > > > > For Registry I was thinking...
> > > > >
> > > > > Website - "Registry - A subproject of Apache NiFi"
> > > > > Git - "nifi-registry.git"
> > > > > JIRA "Apache NiFi Registry"
> > > > >
> > > > > So I didn't think there was a case where it would be referred to as
> > > > > only "Apache Registry", but if sub-project names are trademarked on
> > > > > their own then I do agree we would likely have to call it "NiFi
> > > > > Registry".
> > > > >
> > > > >
> > > > > On Fri, Feb 10, 2017 at 12:21 PM, Joe Percivall <
> > jperciv...@apache.org
> > > >
> > > > wrote:
> > > > >> I 100% agree with Mike and was actually in the process of writing
> a
> > > very
> > > > >> similar response. Just having "Registry" as the name will mean the
> > > > >> trademark will be "Apache Registry" and I don't think that conveys
> > the
> > > > >> specificity of the sub-project. I'd much prefer something like
> NiFi
> > > > >> Registry like the initial discussion had.
> > > > >>
> > > > >>
> > > > >> Joe
> > > > >>
> > > > >> On Fri, Feb 10, 2017 at 12:19 PM, Michael Moser <
> moser...@gmail.com
> > >
> > > > wrote:
> > > > >>
> > > > >>> I am in favor of the concept but the name made me pause.  I did a
> > > > Google
> > > > >>> search of "apache registry" and found an existing Perl module
> > called
> > > > >>> Apache::Registry.  Should I be worried about potential naming
> > > > confusion?
> > > > >>>
> > > > >>> -- Mike
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Feb 10, 2017 at 12:16 PM, Oleg Zhurakousky <
> > > > >>> ozhurakou...@hortonworks.com> wrote:
> > > > >>>
> > > > >>> > +1 Here as well. We desperately need it.
> > > > >>> >
> > > > >>> > > On Feb 10, 2017, at 12:11 PM, Jeremy Dyer 
> > > > wrote:
> > > > >>> > >
> > > > >>> > > +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 <
> > > > mattyb...@apache.org>
> > > > >>> > wrote:
> > > > >>> > >
> > > > >>> > >> +1 binding
> > > > >>> > >>
> > > > >>> > >> On Fri, Feb 10, 2017 at 11:40 AM, Bryan Bende <
> > bbe...@gmail.com
> > > >
> > > > >>> 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
> > > > >>>

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

[Yolanda Davis]

+1 (non-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
>



-- 
--
yolanda.m.da...@gmail.com
@YolandaMDavis

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

[Peter Wicks (pwicks)]

+1 (non-binding)

-Original Message-
From: Bryan Bende [mailto:bbe...@gmail.com] 
Sent: Friday, February 10, 2017 9:41 AM
To: dev@nifi.apache.org
Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi

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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Joe Skora]

+1 binding

On Fri, Feb 10, 2017 at 2:09 PM, Peter Wicks (pwicks) 
wrote:

> +1 (non-binding)
>
> -Original Message-
> From: Bryan Bende [mailto:bbe...@gmail.com]
> Sent: Friday, February 10, 2017 9:41 AM
> To: dev@nifi.apache.org
> Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi
>
> 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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Jennifer Barnabee]

+1 binding

Sent from my iPhone

> On Feb 10, 2017, at 2:55 PM, Joe Skora  wrote:
> 
> +1 binding
> 
> On Fri, Feb 10, 2017 at 2:09 PM, Peter Wicks (pwicks) 
> wrote:
> 
>> +1 (non-binding)
>> 
>> -Original Message-
>> From: Bryan Bende [mailto:bbe...@gmail.com]
>> Sent: Friday, February 10, 2017 9:41 AM
>> To: dev@nifi.apache.org
>> Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi
>> 
>> 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
>> 

PR Builds

[Otto Fowler]

Hi,

I submitted my first PR today, but I’m confused about the build status.
Every PR against the project looks like it is failed in some way. Is there
an explanation for this?

Re: PR Builds

[Joe Witt]

Otto,

We get fairly sketchy results with Travis due to build time/timeouts
as it is a very limited infrastructure.  We're evaluating ways to make
that more reliable because passing PR/builds do help ease PR review.
The appveyor builds are always broken at this point.

But, you're PR is in and will get reviewed.  It is really interesting
that you've run into these osx issues.  Many of us build on OSX
non-stop so it is curious but we'll check it out.

Thanks for contributing!

Joe

On Fri, Feb 10, 2017 at 3:38 PM, Otto Fowler  wrote:
> Hi,
>
> I submitted my first PR today, but I’m confused about the build status.
> Every PR against the project looks like it is failed in some way. Is there
> an explanation for this?

Re: PR Builds

[Otto Fowler]

I see the same thing on Apache Metron project ( incubating ) and we are
fighting the same types of problems with travis - log size and build times
etc.


On February 10, 2017 at 15:49:06, Joe Witt (joe.w...@gmail.com) wrote:

Otto,

We get fairly sketchy results with Travis due to build time/timeouts
as it is a very limited infrastructure. We're evaluating ways to make
that more reliable because passing PR/builds do help ease PR review.
The appveyor builds are always broken at this point.

But, you're PR is in and will get reviewed. It is really interesting
that you've run into these osx issues. Many of us build on OSX
non-stop so it is curious but we'll check it out.

Thanks for contributing!

Joe

On Fri, Feb 10, 2017 at 3:38 PM, Otto Fowler 
wrote:
> Hi,
>
> I submitted my first PR today, but I’m confused about the build status.
> Every PR against the project looks like it is failed in some way. Is
there
> an explanation for this?

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

[Koji Kawamura]

+1 (non-binding)

On Feb 11, 2017 5:37 AM, "Jennifer Barnabee" 
wrote:

+1 binding

Sent from my iPhone

> On Feb 10, 2017, at 2:55 PM, Joe Skora  wrote:
>
> +1 binding
>
> On Fri, Feb 10, 2017 at 2:09 PM, Peter Wicks (pwicks) 
> wrote:
>
>> +1 (non-binding)
>>
>> -Original Message-
>> From: Bryan Bende [mailto:bbe...@gmail.com]
>> Sent: Friday, February 10, 2017 9:41 AM
>> To: dev@nifi.apache.org
>> Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi
>>
>> 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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[u...@moosheimer.com]

+1 (non-binding)

Uwe

> Am 10.02.2017 um 22:18 schrieb Koji Kawamura :
> 
> +1 (non-binding)
> 
> On Feb 11, 2017 5:37 AM, "Jennifer Barnabee" 
> wrote:
> 
> +1 binding
> 
> Sent from my iPhone
> 
>> On Feb 10, 2017, at 2:55 PM, Joe Skora  wrote:
>> 
>> +1 binding
>> 
>> On Fri, Feb 10, 2017 at 2:09 PM, Peter Wicks (pwicks) 
>> wrote:
>> 
>>> +1 (non-binding)
>>> 
>>> -Original Message-
>>> From: Bryan Bende [mailto:bbe...@gmail.com]
>>> Sent: Friday, February 10, 2017 9:41 AM
>>> To: dev@nifi.apache.org
>>> Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi
>>> 
>>> 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: [VOTE] Establish Registry, a sub-project of Apache NiFi

[Andrew Psaltis]

+1 non-binding This will be an awesome addition.  Looking forward to
helping out.


On Fri, Feb 10, 2017 at 17:26 u...@moosheimer.com  wrote:

> +1 (non-binding)
>
> Uwe
>
> > Am 10.02.2017 um 22:18 schrieb Koji Kawamura :
> >
> > +1 (non-binding)
> >
> > On Feb 11, 2017 5:37 AM, "Jennifer Barnabee" <
> jennifer.barna...@gmail.com>
> > wrote:
> >
> > +1 binding
> >
> > Sent from my iPhone
> >
> >> On Feb 10, 2017, at 2:55 PM, Joe Skora  wrote:
> >>
> >> +1 binding
> >>
> >> On Fri, Feb 10, 2017 at 2:09 PM, Peter Wicks (pwicks) <
> pwi...@micron.com>
> >> wrote:
> >>
> >>> +1 (non-binding)
> >>>
> >>> -Original Message-
> >>> From: Bryan Bende [mailto:bbe...@gmail.com]
> >>> Sent: Friday, February 10, 2017 9:41 AM
> >>> To: dev@nifi.apache.org
> >>> Subject: [VOTE] Establish Registry, a sub-project of Apache NiFi
> >>>
> >>> 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
> >>>
>
-- 
Thanks,
Andrew

Subscribe to my book: Streaming Data 

twiiter: @itmdata 

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

[Andre]

+1 binding

On Sat, Feb 11, 2017 at 3: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: PR Builds

[Andre]

Joe,

Perhaps we should float the following feature to the Apache INFRA folks?

https://github.com/travis-ci/beta-features/issues/3


I am sure most ASF projects would incredibly benefit from travis queue
deduping.

Cheers

On Sat, Feb 11, 2017 at 7:49 AM, Joe Witt  wrote:

> Otto,
>
> We get fairly sketchy results with Travis due to build time/timeouts
> as it is a very limited infrastructure.  We're evaluating ways to make
> that more reliable because passing PR/builds do help ease PR review.
> The appveyor builds are always broken at this point.
>
> But, you're PR is in and will get reviewed.  It is really interesting
> that you've run into these osx issues.  Many of us build on OSX
> non-stop so it is curious but we'll check it out.
>
> Thanks for contributing!
>
> Joe
>
> On Fri, Feb 10, 2017 at 3:38 PM, Otto Fowler 
> wrote:
> > Hi,
> >
> > I submitted my first PR today, but I’m confused about the build status.
> > Every PR against the project looks like it is failed in some way. Is
> there
> > an explanation for this?
>

Re: Build failure on Mac OS X with DS_STORE files

[Koji Kawamura]

Thanks Otto, I reviewed pr1497 and merged it.
For the getting started page, I assume you were referring this quick start.
https://nifi.apache.org/quickstart.html

I've modified the Java 8 version description as follows:
"You need a recent Java 8 (or newer) JDK for the 1.x NiFi line. Older
Java 8 (such as 1.8.0_31) is known to fail with some unit tests,
ensure to use the most recent version. The 0.x line works on Java 7 or
newer."
https://github.com/apache/nifi-site/blob/master/src/pages/markdown/quickstart.md#build-steps

I think it takes a while for the HTML web page gets synchronized.

On Sat, Feb 11, 2017 at 12:17 AM, Otto Fowler  wrote:
> https://github.com/apache/nifi/pull/1497
>
>
> On February 9, 2017 at 09:19:21, Koji Kawamura (ijokaruma...@gmail.com)
> wrote:
>
> Thanks! Please ping me when the PR is ready.
>
> On Thu, Feb 9, 2017 at 11:15 PM, Otto Fowler 
> wrote:
>> Sure - I see what you mean, that is a much better approach.
>> I will certainly do that.
>>
>>
>>
>> On February 9, 2017 at 09:02:05, Koji Kawamura (ijokaruma...@gmail.com)
>> wrote:
>>
>> Hi Otto,
>>
>> Thanks for reporting this. I personally haven't encountered this
>> issue, but as described here [1], when I opened the directory that the
>> test uses by Mac Finder application, and changed view as icon and move
>> the icon position, then a .DS_Store file was created.
>>
>> I agree with your workaround and I think we should resolve the issue.
>> By looking at the usage of that method, such as DBCPConnectionPool, or
>> JoltTransformJSON, those uses file name filter like this:
>>
>> (dir, name) -> name != null && name.endsWith(".jar")
>>
>> While filtering out specific .DS_Store works, targeting only name
>> ending with .jar looks more generic work around.
>>
>> Would you mind open a JIRA and send a PR? I'd happy to review!
>>
>> Thanks,
>> Koji
>>
>> On Thu, Feb 9, 2017 at 1:20 PM, Otto Fowler 
>> wrote:
>>> If it turns out that this *is* something you would like addressed, I can
>>> do
>>> the jira and the PR
>>>
>>>
>>> On February 8, 2017 at 23:13:16, Otto Fowler (ottobackwa...@gmail.com)
>>> wrote:
>>>
>>> @Test
>>> public void testGetURLsForClasspathWithDirectory() throws
>>> MalformedURLException {
>>> final String jarFilePath = "src/test/resources/TestClassLoaderUtils";
>>> URL[] urls = ClassLoaderUtils.getURLsForClasspath(jarFilePath,
>>> (dir,name)->name.compareTo(".DS_Store") == 0, false);
>>> assertEquals(2, urls.length);
>>> }
>>>
>>>
>>> resolves the issue, and I am able to build everything.
>>>
>>>
>>> On February 8, 2017 at 22:39:53, Otto Fowler (ottobackwa...@gmail.com)
>>> wrote:
>>>
>>> Hi,
>>>
>>> I’m trying to build master on Mac OS X, following the instructions from
>>> the
>>> site linked in the README.md.
>>>
>>> My build is failing because the unit test:
>>> testGetURLsForClasspathWithDirectory
>>> in TestClassLoaderUtils.
>>>
>>> It is trying to URLs from a directory, and is expecting 2, but gets 3,
>>> because the DS_STORE is detected and has an url built and returned for
>>> it.
>>>
>>> The test does not pass in a FileNamesFilter, which could be used to
>>> filter
>>> these files out I suppose.
>>>
>>> I am wondering if anyone is building successfully on Mac OS X?

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

[Brandon DeVries]

+1 binding
On Fri, Feb 10, 2017 at 6:36 PM Andre  wrote:

> +1 binding
>
> On Sat, Feb 11, 2017 at 3: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
> >
>