Re: [DISCUSS] Change Apache NiFi Fluid Design System naming

[Scott Aslan]

Good timing as we're close to ready for a first nifi-fds release.

I would definitely favor us keeping the 'nifi-fds' naming as that means I
dont have to change a bunch of code so Apache NiFi Flow Design System does
that just fine. I will take care of updating the readme and other areas we
need to change but we can keep the repo as-is with this.

The descriptive name is better, generic, and consistent with some of the
discuss thread feedback a while back anyway.

I'll wait to kick off the release for the outcome of this discussion and
vote.

I'm +1 on this.

Thanks

On Wed, May 16, 2018 at 2:46 PM, Rob Moran  wrote:

> I think it's important to highlight that for nifi-fds the 'f' part of the
> name was for 'fluid.' This is part of a FLUID product design system [1] to
> which I also contribute, that at the time was an internal concept, but is
> now being described in a public manner. However, nifi-fds is partially
> inspired by FLUID concepts as well as others. Specifically, Material Design
> [2] and Teradata's Covalent UI Platform [3].
>
> We should change the name to reflect that what we're aiming for is a set of
> reusable UI components that the NiFi ecosystem can leverage. The UI
> components are inspired by these design systems, and will possibly be
> influenced by others as it evolves.
>
> Since we've already established the FDS naming scheme, I propose a simple
> path would be to call it the Apache NiFi *Flow* Design System rather than a
> unique/standalone term. This way the nifi-fds repo will not require a
> change. We can just update the descriptions.
>
> I assume we should vote on this if others agree?
>
> [1] http://productdesign.hortonworks.com/
> [2] https://material.io/design/
> [3] https://teradata.github.io/covalent/#/
>

Sync is stuck again

[Mike Thomsen]

Mark pushed a big commit and it looks like GitHub is stuck on the sync.
Wanted to let anyone doing reviews know.

[DISCUSS] Change Apache NiFi Fluid Design System naming

[Rob Moran]

I think it's important to highlight that for nifi-fds the 'f' part of the
name was for 'fluid.' This is part of a FLUID product design system [1] to
which I also contribute, that at the time was an internal concept, but is
now being described in a public manner. However, nifi-fds is partially
inspired by FLUID concepts as well as others. Specifically, Material Design
[2] and Teradata's Covalent UI Platform [3].

We should change the name to reflect that what we're aiming for is a set of
reusable UI components that the NiFi ecosystem can leverage. The UI
components are inspired by these design systems, and will possibly be
influenced by others as it evolves.

Since we've already established the FDS naming scheme, I propose a simple
path would be to call it the Apache NiFi *Flow* Design System rather than a
unique/standalone term. This way the nifi-fds repo will not require a
change. We can just update the descriptions.

I assume we should vote on this if others agree?

[1] http://productdesign.hortonworks.com/
[2] https://material.io/design/
[3] https://teradata.github.io/covalent/#/

Handling an error and sys.exit from python in ExecuteScript

[James McMahon]

Hello. I am using an ExecuteScript processor to run a python script in the
NiFi jython environment. Early in my script I try to get user and group
info from my ldap server. It works, but I want to properly handle the case
where the ldap server is down. If it is down and I get an ldap error in the
following try/except, how should I feed that back to and handle that in the
ExecuteScript processor? Since I've not yet read in any flow files at this
point, do I even need to do anything other than simply allow the script to
fail which should throw a yellow warning from the processor and block
flowfile processing?

My try/except:
try:
 # code to access uid and gid info from ldap
except ldap.LDAPError, e:
 print e
 sys.exit(0)

Thanks for any help.

Re: Handling an error and sys.exit from python in ExecuteScript

[Mike Thomsen]

I think what you'd want to do is something like this:

session.yield()
return

On Wed, May 16, 2018 at 11:03 AM James McMahon  wrote:

> Hello. I am using an ExecuteScript processor to run a python script in the
> NiFi jython environment. Early in my script I try to get user and group
> info from my ldap server. It works, but I want to properly handle the case
> where the ldap server is down. If it is down and I get an ldap error in the
> following try/except, how should I feed that back to and handle that in the
> ExecuteScript processor? Since I've not yet read in any flow files at this
> point, do I even need to do anything other than simply allow the script to
> fail which should throw a yellow warning from the processor and block
> flowfile processing?
>
> My try/except:
> try:
>  # code to access uid and gid info from ldap
> except ldap.LDAPError, e:
>  print e
>  sys.exit(0)
>
> Thanks for any help.
>

PR AppVeyor build failure

[Mark Bean]

It appears the AppVeyor build failed on my PR [1]. It also appears that it
simply timed out after 90 minutes. Is there a way to re-run this check?

[1] https://github.com/apache/nifi/pull/2703

Thanks,
Mark

[OT] Speaker wanted for Nifi talk at german data-centric conference

[Bernd Fondermann]

Hi all,

Sorry to disrupt.

I'm looking for a speaker willing to present an entry-level talk about Nifi at 
a data-centric conference in Heidelberg end of September. Preferred language 
would be German, but English is an option.

Please contact me for details at ber...@apache.org.

Thanks,

   Bernd