Re: apache nifi oscon briefing

[Jennifer Barnabee]

Fine by me. It would be a good addition. 

Sent from my iPhone

> On Aug 20, 2015, at 9:04 PM, Joe Witt  wrote:
> 
> Team,
> 
> Does anyone object to me adding this briefing to our apache nifi webcasts 
> page?
> 
> https://www.youtube.com/watch?v=sQCgtCoZyFQ
> 
> It is the talk I gave at OSCON this July on Apache NiFi and its
> relationship to messaging and dataflow.
> 
> After a couple days if all seems fine I'll go ahead and update the
> site to point to it.
> 
> Thanks
> Joe

Re: [VOTE] Release Apache NiFi 0.3.0

[Jennifer Barnabee]

Everything checked out for me.

+1 (binding) - Release this package as nifi-0.3.0

-Jenn

On Mon, Sep 14, 2015 at 11:13 PM, Matt Gilman 
wrote:

> Hello
> I am pleased to be calling this vote for the source release of Apache NiFi
> 0.3.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1060
>
> The Git tag is nifi-0.3.0-RC1
> The Git commit ID is 2ec735e35025fed3c63d51128ec0609ffe1fa7e3
>
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=2ec735e35025fed3c63d51128ec0609ffe1fa7e3
>
> Checksums of nifi-0.3.0-source-release.zip:
> MD5: 0bca350d5d6d9c9a459304253b8121c4
> SHA1: 4b14bf1c0ddc3d970ef44dac93e716e9e6964842
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/mcgilman.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 89 issue was closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329653
>
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.3.0
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test.  The
> please vote:
>
> [ ] +1 Release this package as nifi-0.3.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>

ExtractText & ReplaceText issues

[Jennifer Barnabee]

All,
I sort of went against the grain and reached out to Mark Payne directly
with some questions; whereas, I should have posted my issue here for a
wider discussion... Let me recap...

We are using NiFi-0.3.0.

In our flow, we've been using some ExtractText and ReplaceText processors,
along with HandleHTTPRequest/Response processors. We had a fair number of
the ExtractText processors, and the maximum buffer size we set on them was
10 MB each. As a result, we encountered out-of-memory issues. Mark made the
following recommendations, which might be useful to other people. I'd also
be interested to know whether other people have had problems with this...

Ways to deal with OOM issues when using HTTP processors and ExtractText and
Replace Text processors:

-Reduce the max size configured for HttpContextMap controller service

-Reduce the size of the buffers if you can for ReplaceText, ExtractText

-Increase heap size to 1GB

-If increasing the heap does not help, do a Java Heap Dump

Use the Eclipse Memory Analyzer to find out where all the memory is being
eaten up. This can show you really quickly exactly what is eating up your
heap.

To do this, look at the contents of $NIFI_HOME/bin/nifi.pid to get the pid
of the nifi process.

run: $JAVA_HOME/bin/jmap -dump:format=b,file=nifi-heap-dump.bin
 

Eclipse Memory Analyzer will show exactly what class (which processor,
which part of the framework, etc) is using the heap.The heap dump option
will probably take a few hours to figure out how to analyze the heap dump,
but it is well worth the time. Not only will it give you a definitive
answer about what is going on, as a java developer it is invaluable to
learn so that you can figure out exactly what your software is doing.

Another question from me: Can you use AppDynamics to figure this out also?

-Jenn

Re: Doc change in web content

[Jennifer Barnabee]

Keith,
Thanks for bringing this to our attention. I have created a ticket to fix
this [1]. There are some other things that need to be fixed in the Admin
Guide as well. I hope to get around to these soon!

Cheers,
Jenn

[1] https://issues.apache.org/jira/browse/NIFI-1024



On Mon, Oct 5, 2015 at 12:57 PM, Keith S. Sundberg <
kssundb...@multiservice.com> wrote:

> I'm sorry if I should submit this another way, but I found this in the
> website which should be corrected.  I contemplated setting up a contributor
> account, but it's not a problem with the code for nifi so it didn't make
> sense to me.  I emailed this address since it was referenced at the top of
> the webpage in question.
>
>
> On this page:
>
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#clustering
> <
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#clustering
> >
>
> You can find a reference to:
> nifi.cluster.protocol.manager.port
>
> But I believe it should instead be:
> nifi.cluster.manager.protocol.port
>
> … which is the configuration line in the provided template for
> 0.3.0.
>
> Thank you,
>
> Keith Sundberg
> Enterprise Architect
> Multi Service Technology Solutions
>
> +1-913-663-9718 - w
> +1-816-585-1699 - m
> +1-913-451-2367 - f
> kssundb...@multiservice.com 
>
> --
>
>
> --
> This email is intended solely for the use of the addressee and may
> contain information that is confidential, proprietary, or both.
> If you receive this email in error please immediately notify the
> sender and delete the email..
> --
>
>

Re: Configuration Driven Property Updates

[Jennifer Barnabee]

+1 for the second option.

On Thu, Oct 22, 2015 at 9:08 AM, Mark Payne  wrote:

> I two thoughts on this concept. Firstly is the notion of Controller
> Services. Rather than having properties that
> change significantly depending on the strategy selected, each strategy
> could be implemented as a separate
> Controller Service. Then, in the Processor you'd just choose which
> Controller Service to use. This allows the
> properties that need to be configured for that strategy to move into the
> Controller Service itself.
>
> The second thought, is one that I had proposed a while back, but it never
> picked up any traction. The idea is
> to have properties "depend" on other properties. So, for instance, you
> could say Property B is only applicable
> if Property A is set to Allowable Value 1 or Allowable Value 2. If
> Property A is not set or is set to Allowable Value
> 3, for instance, then Property B is not even shown in the UI.
>
> The nice thing about the second option is that it would make the UI
> cleaner for existing Processors. For instance,
> we could indicate in CompressContent that the "Compression Level" property
> should not even be shown if the
> mode is set to Decompress. Currently, we just document that "This property
> is ignored unless mode is Compress."
> I would much prefer to not even show the property at all.
>
> Any thoughts?
>
> -Mark
>
>
>
> > On Oct 21, 2015, at 10:11 PM, Joe Witt  wrote:
> >
> > Not to trivialize this but curious if we added an 'apply' type option
> > there would that be a sufficient user experience?  The core point is
> > once you select a new strategy we need to send that fact to the server
> > to see what effect that has.  That happens when you hit ok but as you
> > note that closes the dialogue and requires you to reopen it which is
> > just sort of awkward.  So would an 'ok' option which applies the
> > changes and talks to the server and gets new info but doesn't close
> > the dialogue make this good enough?
> >
> > Thanks
> > Joe
> >
> > On Wed, Oct 21, 2015 at 6:09 PM, Michael D. Coon
> >  wrote:
> >> Mike,
> >>  Thanks, that is EXACTLY what I'm doing as well :)My current
> version just allows them to set the properties up once…if they need to
> change the selection, they unfortunately have to create a whole new
> processor configuration and delete the old one. Kinda stinks but, as you
> said, current UI doesn't support this particular use case. At least I'm not
> alone! :)
> >> Mike
> >>
> >>
> >>
> >> On Wednesday, October 21, 2015 6:02 PM, Michael Moser <
> moser...@gmail.com> wrote:
> >>
> >>
> >> Mike,
> >>
> >> I have implemented a NiFi processor very similar to what you describe.
> A
> >> ServiceLoader discovers the plugins that are available to the processor
> and
> >> populates the allowableValues of a PropertyDescriptor.
> >>
> >> In the end I don't think there is a way to resolve your
> questions/issues in
> >> the UI.  After you select a plugin, the user will have to save the
> >> processor config, then go back into it to see the new properties that
> you
> >> made available.  And if you change your plugin selection, then the
> >> processor will stay invalid until the user deletes the old properties
> that
> >> are no longer needed.  The NiFi framework just doesn't support this edge
> >> case.
> >>
> >> In the end, for my processor, I just made all properties from all
> plugins
> >> available all the time.  I named the properties to begin with the
> plugin's
> >> name to help users keep track of which plugin they applied to.
> >>
> >> -- Mike
> >>
> >>
> >>
> >> On Wed, Oct 21, 2015 at 5:50 PM, Michael D. Coon
> 
> >> wrote:
> >>
> >>> Hey Tony,
> >>>   I do have working code but  not in a public repo. I am, in fact,
> trying
> >>> to use NiFi as a backing engine. I think the bottom line is that I
> want to
> >>> be able to add/remove some configuration properties based on the
> settings
> >>> of other configuration properties. For example, I might specify
> "ClassA"
> >>> for property "PluginClass" and the implementation "ClassA" has its own
> set
> >>> of parameters required to operate. I want to expose those on the UI. It
> >>> works as I have it now, but if after setting up "ClassA" as my plugin I
> >>> change the "PluginClass" setting to "ClassB", all of ClassA's
> properties
> >>> stick around even though they are no longer what I'm returning from
> >>> "getSupportedProperties".  It looks like, at least on the version I'm
> >>> using, that NiFi is caching the properties internally and not syncing
> them
> >>> with the properties that I provide through the "getSupportedProperties"
> >>> method. More specifically, if I actually set a value on any of the
> "ClassA"
> >>> required properties, they stick around forever. I would think that
> whatever
> >>> I return from the "getSupportedProperties" method should, in fact, be
> the
> >>> set of properties exposed on the UI. But they fall out of sync if I
> change
> >>> my settings and add/

FAQ page

[Jennifer Barnabee]

I've been slowly adding to the FAQ page on the wiki [1].
Please feel free to add/change what's there. It's good if you can also add
labels at the bottom of the page, as that can make searching work better.
Please also consider listing any tickets that would fix things addressed
and reference the version they will be fixed in. That way, someone using an
older version will have options/guidance. I hope this is a helpful resource.

-Jenn

[1] https://cwiki.apache.org/confluence/display/NIFI/FAQs

Re: [DRAFT][REPORT] Apache NiFi - January 2016

[Jennifer Barnabee]

+1 for me. 

Sent from my iPhone

> On Jan 3, 2016, at 1:04 PM, Joe Witt  wrote:
> 
> NiFi Community,
> 
> Please review the included January 2016 report for the Apache board.
> Please let me know if anything should be added or corrected.
> 
> If the progress made within the community over the past year is any
> indicator then 2016 is shaping up to be a great year!
> 
> Thanks
> Joe
> 
> --
> 
> Report from the Apache NiFi committee [Joe Witt]
> 
> ## Description:
> - Apache NiFi is an easy to use, powerful, and reliable system to process
> and distribute data.
> 
> ## Issues:
> - There are no issues requiring board attention at this time.
> 
> ## Activity:
> - Released NiFi 0.4 with extensive stability and feature enhancements.
> - Upcoming NiFi releases will provide important features frequently
> requested and discussed by the community and as found on feature proposals
> in the NiFi Wiki.  Discussion of moving toward a 1.0 release are underway.
> - Members of the NiFi community have created new or improved integrations
> with several Apache projects including HBase, Kafka, Avro, Flink, and Apex.
> 
> ## Health report:
> - Activity on mailing lists, JIRA, Git remains strong.
> - During the last review cycle the PMC has grown and a newly formed
> committer tier has been established.
> - The pipeline for people progressing toward committer and/or PMC status
> is highly encouraging.
> 
> ## PMC changes:
> 
> - Currently 13 PMC members.
> - One new PMC members added in the last 3 months
> - Last PMC addition was Sean Busbey on Wed Nov 25 2015
> 
> ## Committer base changes:
> 
> - Currently 17 committers.
> - New commmitters:
>- Ricky Saltzer was added as a committer on Wed Oct 21 2015
>- Toivo Adams was added as a committer on Tue Nov 03 2015
>- Sean Busbey was added as a committer on Wed Nov 25 2015
>- Michael W Moser was added as a committer on Sun Oct 18 2015
>- Joe Percivall was added as a committer on Mon Dec 14 2015
> 
> ## Releases:
> 
> - nifi-0.4.1 on Wed Dec 23 2015
> - nifi-0.4.0 on Mon Dec 14 2015
> 
> ## Mailing list activity:
> 
> - us...@nifi.apache.org:
>- 200 subscribers (up 66 in the last 3 months):
>- 726 emails sent to list (343 in previous quarter)
> 
> - dev@nifi.apache.org:
>- 203 subscribers (up 37 in the last 3 months):
>- 1413 emails sent to list (968 in previous quarter)
> 
> - comm...@nifi.apache.org:
>- 36 subscribers
> 
> ## JIRA activity:
> 
> - 324 JIRA tickets created in the last 3 months
> - 215 JIRA tickets closed/resolved in the last 3 months

Re: Redesign User Interface (UI)

[Jennifer Barnabee]

Hi Rob,
I think the UI improvements look really good, and this is very exciting.

I wonder if there has been any thought around making each component type
look a little more distinguishable. That is to say, processors, process
groups, and remote process groups are all still very similar looking. So,
just at a glance, it isn't easy to tell one from another without taking a
closer look.

Other than that, I love the icons and the way you have moved things around
and made better use of the real estate on the screen. Everything looks more
refined as well. The styling is really nice.
-Jenn

On Wed, Jan 6, 2016 at 1:08 PM, Rob Moran  wrote:

> Greetings ​​NiFi community,
>
> NIFI-1323 [1] has been mentioned in (at least one) previous thread. In case
> you are unaware, it involves beginning work on a series of UI improvements.
>
> I'd like to point your attention to the wiki page [2] where you can read up
> on factors that are driving this effort.
>
> [1] https://issues.apache.org/jira/browse/NIFI-1323
> [2]
> https://cwiki.apache.org/confluence/display/NIFI/Redesign+User+Interface
>
> Thanks,
> Rob
>

Re: [DISCUSS] create apache nifi 0.6.1

[Jennifer Barnabee]

+1

On Thu, Mar 31, 2016 at 10:29 AM, Joe Witt  wrote:

> Team,
>
> I propose that we do an Apache NiFi 0.6.1 release.  There are a few
> important findings we've made and put JIRAs/PRs in for over the past
> couple of days.  The most concerning is that I believe we have a
> potential data loss issue introduced in PutKafka.  The general logic
> of that processor is far better now but the handling of stream
> demarcation is broken.  That is now fixed from NIFI-1701.
>
> I am happy to RM this if folks are in agreement.
>
> Thanks
> Joe
>

Re: [VOTE] Establish Apache MiNiFi, a subproject of Apache NIFi

[Jennifer Barnabee]

+1

On Sat, Apr 9, 2016 at 1:13 AM, Joe Witt  wrote:

> Team,
>
> Following a solid discussion [1] in early January regarding
> establishment of MiNiFi as a subproject of NiFi I'd like to call a
> formal vote to record this important community decision and
> established consensus.
>
> Through lazy consensus [2] the repositories were setup for source,
> JIRA, and git-hub mirror [3].  There has since been solid progress and
> discussion on a number of MINIFI JIRAs.  The core goals of MiNiFi have
> been documented on Confluence/Wiki [4].  It was also reported in our
> April 2016 board report that we have established MiNiFi based on these
> things.  But, lets make sure we get this right.
>
> [1] https://s.apache.org/czuz
> [2] https://s.apache.org/Ucxs
> [3]
> https://cwiki.apache.org/confluence/display/NIFI/Supporting+Infrastructure
> [4] https://cwiki.apache.org/confluence/display/NIFI/MiNiFi
>
> I am a +1 and am very excited by the progress made thus far!
>
> The vote will be open for 72 hours and be a majority rule vote.
>
> [ ] +1 Establish Apache MiNiFi, a subproject of Apache NiFi
> [ ]   0 Do not care
> [ ]  -1 Do not establish Apache MiNiFi
>
> Thanks
> Joe
>

Two more updated video tutorials

[Jennifer Barnabee]

Hello NiFi Dev Team -
I've created two more updated NiFi tutorial videos. These are updates to
the "How to Build a Flow" videos - parts 1 & 2 -- that I did before, but
now with the new user interface. You can find the links below, along with
the embed code - in case you want to use them.

I have a question about my use of the Apache NiFi logo in the beginning. Is
that acceptable? Do I need to add any type of copyright or anything with
that? I figured I should ask here - in case others might want to know. I
read the information about the ASF trademark policies, and I saw the
copyright for that logo on the NiFi web site. But I didn't see anything
specifically for the Apache NiFi logo. Do I use the same verbiage? I can
easily update the videos to either remove the logo or add whatever is
appropriate.

Thanks.
-Jenn



*How to Build a Flow Part 1 *- https://youtu.be/bzqP-Loyq-Y

Embed code:
https://www.youtube.com/embed/bzqP-Loyq-Y"; frameborder="0"
allowfullscreen>



*How to Build a Flow Part 2 *- https://youtu.be/YVMUnfjMGVk

Embed code:
https://www.youtube.com/embed/YVMUnfjMGVk"; frameborder="0"
allowfullscreen>

Re: Two more updated video tutorials

[Jennifer Barnabee]

Thanks, Joe & Joe!
I've added that text to the descriptions on the videos.

Cheers,
Jenn

On Fri, Feb 3, 2017 at 10:10 AM, Joe Percivall 
wrote:

> Jenn,
>
> I agree with Joe on the usage of the trademark and the addition of the
> video description.
>
> I also just want to express my gratitude for you making these videos. I've
> had to onboard/introduce a number of people to NiFi and always reference
> your videos. They're great!
>
> Thanks Jenn,
> Joe
>
>
>
> On Fri, Feb 3, 2017 at 9:30 AM, Joe Witt  wrote:
>
> > Jenn,
> >
> > It is certainly appropriate to use the logo there.  Probably is good
> > to have the description of the video indicate that Apache, NiFi, and
> > Apache NiFi are trademarks of the Apache Software Foundation.  As
> > found here: https://www.apache.org/foundation/marks/faq/#booktitle
> >
> > It looks like a good description field would be
> >
> > Apache®, Apache NiFi, NiFi, and the tear drop logo are either
> > registered trademarks or trademarks of the Apache Software Foundation
> > in the United States and/or other countries. No endorsement by The
> > Apache Software Foundation is implied by the use of these marks.
> >
> > That said I'm by no means an expert on the exact rules but this seems
> > reasonable.
> >
> > Great videos!
> >
> > Thanks
> > Joe
> >
> > On Fri, Feb 3, 2017 at 8:22 AM, Jennifer Barnabee
> >  wrote:
> > > Hello NiFi Dev Team -
> > > I've created two more updated NiFi tutorial videos. These are updates
> to
> > > the "How to Build a Flow" videos - parts 1 & 2 -- that I did before,
> but
> > > now with the new user interface. You can find the links below, along
> with
> > > the embed code - in case you want to use them.
> > >
> > > I have a question about my use of the Apache NiFi logo in the
> beginning.
> > Is
> > > that acceptable? Do I need to add any type of copyright or anything
> with
> > > that? I figured I should ask here - in case others might want to know.
> I
> > > read the information about the ASF trademark policies, and I saw the
> > > copyright for that logo on the NiFi web site. But I didn't see anything
> > > specifically for the Apache NiFi logo. Do I use the same verbiage? I
> can
> > > easily update the videos to either remove the logo or add whatever is
> > > appropriate.
> > >
> > > Thanks.
> > > -Jenn
> > >
> > >
> > >
> > > *How to Build a Flow Part 1 *- https://youtu.be/bzqP-Loyq-Y
> > >
> > > Embed code:
> > > https://www.youtube.com/embed/bzqP-Loyq-Y"; frameborder="0"
> > > allowfullscreen>
> > >
> > >
> > >
> > > *How to Build a Flow Part 2 *- https://youtu.be/YVMUnfjMGVk
> > >
> > > Embed code:
> > > https://www.youtube.com/embed/YVMUnfjMGVk"; frameborder="0"
> > > allowfullscreen>
> >
>
>
>
> --
> *Joe Percivall*
> linkedin.com/in/Percivall
> e: jperciv...@apache.com
>

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

Re: [DISCUSS] 1.0 Beta Release

[Jennifer Barnabee]

+1

Sent from my iPhone

> On Aug 1, 2016, at 10:14 PM, Joe Percivall  
> wrote:
> 
> Hey Team,
> 
> The big ticket elements of 1.0 look to be in a pretty good state. Lots of 
> things left to tighten up, primarily docs and bug fixes, but, it seems wise 
> for a major release like this to first kick out a Beta[1]. The relevant 
> section of the Apache.org link:
> 
>Releases that are believed to be usable by testers and developers outside 
> the project, but perhaps not yet stable in terms of features or 
> functionality, are usually referred to as "beta" or "unstable". 
> 
> This will enable us to will open up to the broader base of users that 
> normally don't build from source to help test and give us a couple weeks of 
> feedback to work with before we do a formal 1.0 release vote. 
> 
> If no one has any objections, I will start an RC vote for it later this week.
> 
> [1] http://www.apache.org/dev/release.html#release-types
> 
> Joe
> - - - - - - 
> Joseph Percivall
> linkedin.com/in/Percivall
> e: joeperciv...@yahoo.com

Re: [ANNOUNCE] New Apache NiFi Committer Rob Moran

[Jennifer Barnabee]

Congrats, Rob!

On Mon, Sep 19, 2016 at 3:36 PM, Rob Moran  wrote:

> Thanks everyone! I look forward to continuing the great progress we've
> made, and trying to make us look a little better while we do it ;)
>
> Rob
>
> On Mon, Sep 19, 2016 at 3:08 PM, Tony Kurc  wrote:
>
> > On behalf of the Apache NiFI PMC, I am very pleased to announce that Rob
> > Moran has accepted the PMC's invitation to become a committer on the
> Apache
> > NiFi project. We greatly appreciate all of Rob's hard work and generous
> > contributions to the project. We look forward to his continued
> involvement
> > in the project.
> >
> > Among other things, Rob has been responsible for a lot of the look and
> feel
> > of the NiFi user interface, to include the awesome logos!
> >
> > Welcome and congratulations!
> >
> > Tony
> >
>

New UI Overview video

[Jennifer Barnabee]

Hello Apache NiFi team -
I created the following update to the toolbar overview video to show off
the new UI:

https://youtu.be/Y5znvcJ_NWo

If you like it, feel free to use it to replace the one entitled
"Screencast: NiFi Toolbar Overview" on the Apache NiFi web site. (It has
the creative commons license.) I suggest calling this one, "Screencast:
NiFi User Interface Overview".

I hope to update the other videos using the new UI as well.

Cheers,
Jenn

P.S. Here is the embed code:

https://www.youtube.com/embed/Y5znvcJ_NWo"; frameborder="0"
allowfullscreen>

Re: New UI Overview video

[Jennifer Barnabee]

Thanks, Matt!

Sent from my iPhone

> On Dec 1, 2016, at 3:54 PM, Matt Gilman  wrote:
> 
> Thanks Jenn!
> 
> The new video is awesome. I just published it to the site. It is live now.
> 
> Matt
> 
>> On Thu, Dec 1, 2016 at 1:16 PM, Andy LoPresto  wrote:
>> 
>> Jenn,
>> 
>> This is great stuff. Thanks for creating these. We will get them on the
>> site quickly.
>> 
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> 
>> On Dec 1, 2016, at 3:32 AM, Jennifer Barnabee 
>> wrote:
>> 
>> Hello Apache NiFi team -
>> I created the following update to the toolbar overview video to show off
>> the new UI:
>> 
>> https://youtu.be/Y5znvcJ_NWo
>> 
>> If you like it, feel free to use it to replace the one entitled
>> "Screencast: NiFi Toolbar Overview" on the Apache NiFi web site. (It has
>> the creative commons license.) I suggest calling this one, "Screencast:
>> NiFi User Interface Overview".
>> 
>> I hope to update the other videos using the new UI as well.
>> 
>> Cheers,
>> Jenn
>> 
>> P.S. Here is the embed code:
>> 
>> https://www.youtube.com/embed/Y5znvcJ_NWo"; frameborder="0"
>> allowfullscreen>
>> 
>> 
>>