Every one I have talked to, have mentioned things like: Centralized dash board to monitor all their NIFI instances (some of the enterprises are projected to be in the hundreds of instances). A way to remotely change processor state or properties.
Corey On Fri, May 15, 2015 at 9:40 AM, Mark Payne <[email protected]> wrote: > Matt, > > When we created the Spark Receiver, we did exactly that: we factored out a > SiteToSite Client. The Spark Receiver is a very simple wrapper around that > library. > > You can pull the library in with the following dependency: > > <dependency> > <groupId>org.apache.nifi</groupId> > <artifactId>nifi-site-to-site-client</artifactId> > <version>0.0.2-incubating</version> > </dependency> > > The main starting point, where you'll find most of the JavaDocs on how to > use it are also available at: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=blob_plain;f=nifi/nifi-commons/nifi-site-to-site-client/src/main/java/org/apache/nifi/remote/client/SiteToSiteClient.java;hb=refs/heads/develop > > If you have any issues making use of that, let us know and we'll help out! > > Thanks > -Mark > > > ---------------------------------------- > > From: [email protected] > > Date: Fri, 15 May 2015 13:34:17 +0000 > > Subject: Re: Planning for the next release > > To: [email protected] > > > > I think it would be awesome to have a java driver for sending and > receiving > > data to/from a nifi flow directly, similar to the nifi-spark-receiver. > > Then it would make it much easier to directly link with any java > > application or something like storm. Currently our team is using kafka to > > bridge that gap, but it would be great if that could be streamlined by > > going directly to and from a nifi flow. > > > > Thanks! > > Matt > > > > On Thu, May 14, 2015 at 10:58 PM Sean Busbey <[email protected]> > wrote: > > > >> how easy / hard is it to dynamically add and remove nodes from cluster > mode > >> right now? Being able to scale elastically would make gaining ground in > >> cloud deployments way easier. > >> > >> On Thu, May 14, 2015 at 9:29 PM, Joe Witt <[email protected]> wrote: > >> > >>> All, > >>> > >>> With the 0.1.0 release hopefully soon available it is time to turn > >>> towards the next release or so and get a sense of what we should focus > >>> on. > >>> > >>> This should include both 0.1.x but also 0.2.0. > >>> > >>> Obviously first and foremost we need to work the existing PRs and > >>> patches that exist. > >>> > >>> Beyond that we have slated the following so far: > >>> > >>> 0.1.1 > >>> > >>> > >> > https://issues.apache.org/jira/browse/NIFI/fixforversion/12332286/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel > >>> > >>> 0.2.0 > >>> > >>> > >> > https://issues.apache.org/jira/browse/NIFI/fixforversion/12329653/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel > >>> > >>> But what i'd like to throw out for general discussion is what are some > >>> of the bigger thematic things we should focus on? Things which will > >>> help further with community growth and utility of the product for > >>> those folks using it now? > >>> > >>> For example: > >>> I'd like to see us start digging into the cluster robustness issues > >>> (HA cluster manager w/ legit leader election, etc..). But there are > >>> other things as well that may be more important sooner. > >>> > >>> Please share your thoughts as this is a great time to effect those > >>> releases. > >>> > >>> Thanks > >>> Joe > >>> > >> > >> > >> > >> -- > >> Sean > >> > > -- Corey Flowers Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information --
