Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Sivaprasanna]

Scott,

I understand the vision. I was actually echoing what Matt said i.e. if the
contributions being made to the sub-project has any supporting changes that
*should* exist in the core-project i.e. NiFi or any other projects that use
this sub-project, they have to be checked by the committer. But you have
made it clear that it's going to be a npm module so I understand it better
now. Disregard my previous comment.

-
Sivaprasanna

On Fri, Feb 23, 2018 at 9:16 AM, Tony Kurc  wrote:

> Is some of the thinking that projects other than nifi projects would use
> this?
>
> On Feb 22, 2018 10:00 PM, "Scott Aslan"  wrote:
>
> > Sivaprasanna,
> >
> > I am not sure I follow exactly what you are saying...
> >
> > NiFi Registry would no longer continue to host a copy of the FDS
> NgModule.
> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a
> client
> > side dependency in its package.json. This would be analogous to how NiFi
> > Registry depends on Angular Material, etc. npm supports the ability to
> > download published packages which are current with the latest stable
> > release of a package. npm *also* supports the ability to develop off
> > of the *master
> > branch (or any other branch really)* of the NiFi FDS. An example of this
> > can be found in the github.io demo here
> >  system/blob/gh-pages/package.
> > json#L45>
> > . By placing that dependency in the package.json for the NiFi Registry
> each
> > subsequent clean build would automatically download the latest master
> > branch of the NiFi FDS sub-project and developers can leverages the
> latest
> > NiFi FDS components.
> >
> > This also brings up a good point about release management. I have also
> > included a prototype of one possible implementation of automating the
> > tagging of a branch and automatically updating release version numbers
> etc.
> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with
> the
> > described grunt task.
> >
> > [1]
> > https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile
> .
> > js#L47
> >
> > [2] https://github.com/scottyaslan/fluid-design-
> system/tree/FDS-0.0.1-RC.0
> >
> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
> sivaprasanna...@gmail.com>
> > wrote:
> >
> > > I agree with Matt. With clear documentation and guides, contributions
> on
> > > the sub-projects can be streamlined and be ensured that the necessary
> > > changes are already available on the core project i.e NiFi. One
> challenge
> > > is that the committer of the sub-project should have the courtesy to
> > check
> > > wether the supporting changes are made available to the core project
> and
> > > track its status but given how contributions are being handled in
> > > nifi-registry project, I don’t think it’s going to be that much of a
> > > headache.
> > >
> > > We could also add to the helper doc mentioning that if the contribution
> > is
> > > going to affect a core component, the contributor needs to add the JIRA
> > id
> > > of the core project’s supporting changes in the sub-projects’ issue
> > > description.
> > >
> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman 
> > > wrote:
> > >
> > > > Joe, Joe,
> > > >
> > > > Regarding the release process... I think it could be similar to how
> > folks
> > > > verified and validated the NiFi Registry release. Guidance was given
> > in a
> > > > helper guide regarding how to obtain/build a branch or PR that
> > references
> > > > the new components. For the Registry release, there was a PR for NiFi
> > > that
> > > > had the supporting changes already available.
> > > >
> > > > We may have this issue any time we release new versions that depend
> on
> > > > another (sub)project.
> > > >
> > > > Matt
> > > >
> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
> jperciv...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Scott,
> > > > >
> > > > > Definitely like the direction of standardizing NiFi and Registry
> > around
> > > > the
> > > > > same set of components, so the user has a common UX. Is there
> > precedent
> > > > for
> > > > > creating a new sub-project just for common components/modules to be
> > > used
> > > > by
> > > > > the top-level, and it's other sub-projects? My concerns are similar
> > to
> > > > > Joe's. Along those lines, if the core problems we're trying to
> > address
> > > is
> > > > > the release process and distribution, is there a less
> "heavy-weight"
> > > > > avenue?
> > > > >
> > > > > In the past, we've also talked about pulling out the core NiFi
> > > framework
> > > > to
> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How we
> go
> > > > about
> > > > > solving this for the UI could be used a model for the core
> framework
> > as
> > > > > well.
> > > > >
> > > > > - Joe
> > > > >
> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> > mikerthom...@gmail.com

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Tony Kurc]

Is some of the thinking that projects other than nifi projects would use
this?

On Feb 22, 2018 10:00 PM, "Scott Aslan"  wrote:

> Sivaprasanna,
>
> I am not sure I follow exactly what you are saying...
>
> NiFi Registry would no longer continue to host a copy of the FDS NgModule.
> Instead, NiFi Registry would just add the NiFi FDS sub-project as a client
> side dependency in its package.json. This would be analogous to how NiFi
> Registry depends on Angular Material, etc. npm supports the ability to
> download published packages which are current with the latest stable
> release of a package. npm *also* supports the ability to develop off
> of the *master
> branch (or any other branch really)* of the NiFi FDS. An example of this
> can be found in the github.io demo here
>  json#L45>
> . By placing that dependency in the package.json for the NiFi Registry each
> subsequent clean build would automatically download the latest master
> branch of the NiFi FDS sub-project and developers can leverages the latest
> NiFi FDS components.
>
> This also brings up a good point about release management. I have also
> included a prototype of one possible implementation of automating the
> tagging of a branch and automatically updating release version numbers etc.
> leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with the
> described grunt task.
>
> [1]
> https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile.
> js#L47
>
> [2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-0.0.1-RC.0
>
> On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna 
> wrote:
>
> > I agree with Matt. With clear documentation and guides, contributions on
> > the sub-projects can be streamlined and be ensured that the necessary
> > changes are already available on the core project i.e NiFi. One challenge
> > is that the committer of the sub-project should have the courtesy to
> check
> > wether the supporting changes are made available to the core project and
> > track its status but given how contributions are being handled in
> > nifi-registry project, I don’t think it’s going to be that much of a
> > headache.
> >
> > We could also add to the helper doc mentioning that if the contribution
> is
> > going to affect a core component, the contributor needs to add the JIRA
> id
> > of the core project’s supporting changes in the sub-projects’ issue
> > description.
> >
> > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman 
> > wrote:
> >
> > > Joe, Joe,
> > >
> > > Regarding the release process... I think it could be similar to how
> folks
> > > verified and validated the NiFi Registry release. Guidance was given
> in a
> > > helper guide regarding how to obtain/build a branch or PR that
> references
> > > the new components. For the Registry release, there was a PR for NiFi
> > that
> > > had the supporting changes already available.
> > >
> > > We may have this issue any time we release new versions that depend on
> > > another (sub)project.
> > >
> > > Matt
> > >
> > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall  >
> > > wrote:
> > >
> > > > Scott,
> > > >
> > > > Definitely like the direction of standardizing NiFi and Registry
> around
> > > the
> > > > same set of components, so the user has a common UX. Is there
> precedent
> > > for
> > > > creating a new sub-project just for common components/modules to be
> > used
> > > by
> > > > the top-level, and it's other sub-projects? My concerns are similar
> to
> > > > Joe's. Along those lines, if the core problems we're trying to
> address
> > is
> > > > the release process and distribution, is there a less "heavy-weight"
> > > > avenue?
> > > >
> > > > In the past, we've also talked about pulling out the core NiFi
> > framework
> > > to
> > > > be shared between NiFi and MiNiFi-Java for similar reasons. How we go
> > > about
> > > > solving this for the UI could be used a model for the core framework
> as
> > > > well.
> > > >
> > > > - Joe
> > > >
> > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> mikerthom...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Also, what sort of framework is the UI being standardized on?
> > Angular?
> > > > > React? Something else?
> > > > >
> > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt 
> > wrote:
> > > > >
> > > > > > Scott
> > > > > >
> > > > > > Ok so extract out the fluid design work you started with NiFi
> > > Registry
> > > > > > to its own codebase which can be rev'd and published to NPM
> making
> > it
> > > > > > easier to consume/reuse across NiFi projects and offers better
> > > > > > consistency.  This sounds interesting.
> > > > > >
> > > > > > In thinking through the additional community effort or the effort
> > > > > > trade-off:
> > > > > > How often do you anticipate we'd be doing releases (and thus

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Scott Aslan]

Sivaprasanna,

I am not sure I follow exactly what you are saying...

NiFi Registry would no longer continue to host a copy of the FDS NgModule.
Instead, NiFi Registry would just add the NiFi FDS sub-project as a client
side dependency in its package.json. This would be analogous to how NiFi
Registry depends on Angular Material, etc. npm supports the ability to
download published packages which are current with the latest stable
release of a package. npm *also* supports the ability to develop off
of the *master
branch (or any other branch really)* of the NiFi FDS. An example of this
can be found in the github.io demo here

. By placing that dependency in the package.json for the NiFi Registry each
subsequent clean build would automatically download the latest master
branch of the NiFi FDS sub-project and developers can leverages the latest
NiFi FDS components.

This also brings up a good point about release management. I have also
included a prototype of one possible implementation of automating the
tagging of a branch and automatically updating release version numbers etc.
leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with the
described grunt task.

[1]
https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile.js#L47

[2] https://github.com/scottyaslan/fluid-design-system/tree/FDS-0.0.1-RC.0

On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna 
wrote:

> I agree with Matt. With clear documentation and guides, contributions on
> the sub-projects can be streamlined and be ensured that the necessary
> changes are already available on the core project i.e NiFi. One challenge
> is that the committer of the sub-project should have the courtesy to check
> wether the supporting changes are made available to the core project and
> track its status but given how contributions are being handled in
> nifi-registry project, I don’t think it’s going to be that much of a
> headache.
>
> We could also add to the helper doc mentioning that if the contribution is
> going to affect a core component, the contributor needs to add the JIRA id
> of the core project’s supporting changes in the sub-projects’ issue
> description.
>
> On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman 
> wrote:
>
> > Joe, Joe,
> >
> > Regarding the release process... I think it could be similar to how folks
> > verified and validated the NiFi Registry release. Guidance was given in a
> > helper guide regarding how to obtain/build a branch or PR that references
> > the new components. For the Registry release, there was a PR for NiFi
> that
> > had the supporting changes already available.
> >
> > We may have this issue any time we release new versions that depend on
> > another (sub)project.
> >
> > Matt
> >
> > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall 
> > wrote:
> >
> > > Scott,
> > >
> > > Definitely like the direction of standardizing NiFi and Registry around
> > the
> > > same set of components, so the user has a common UX. Is there precedent
> > for
> > > creating a new sub-project just for common components/modules to be
> used
> > by
> > > the top-level, and it's other sub-projects? My concerns are similar to
> > > Joe's. Along those lines, if the core problems we're trying to address
> is
> > > the release process and distribution, is there a less "heavy-weight"
> > > avenue?
> > >
> > > In the past, we've also talked about pulling out the core NiFi
> framework
> > to
> > > be shared between NiFi and MiNiFi-Java for similar reasons. How we go
> > about
> > > solving this for the UI could be used a model for the core framework as
> > > well.
> > >
> > > - Joe
> > >
> > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen  >
> > > wrote:
> > >
> > > > Also, what sort of framework is the UI being standardized on?
> Angular?
> > > > React? Something else?
> > > >
> > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt 
> wrote:
> > > >
> > > > > Scott
> > > > >
> > > > > Ok so extract out the fluid design work you started with NiFi
> > Registry
> > > > > to its own codebase which can be rev'd and published to NPM making
> it
> > > > > easier to consume/reuse across NiFi projects and offers better
> > > > > consistency.  This sounds interesting.
> > > > >
> > > > > In thinking through the additional community effort or the effort
> > > > > trade-off:
> > > > > How often do you anticipate we'd be doing releases (and thus
> > > > > validation/voting) for this?
> > > > > How often would those differ from when we'd want to do a NiFi or
> NiFi
> > > > > Registry release?
> > > > > How do you envision the community would be able to help
> vet/validate
> > > > > releases of these modules?
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> scottyas...@gmail.com>
> > > > > 

Re: Re: Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?

[Sivaprasanna]

I believe even if it is where to be made available as part of NiFi REST
API, I think it is internally going to call the start and stop APIs.

On Fri, 23 Feb 2018 at 6:54 AM,  wrote:

> Yes, that is what I do currently.
>
> But I think it will be better if NiFi can support this feature natively.
>
>
>
> 发件人:
> "Andrew Grande" 
> 收件人:
> dev@nifi.apache.org
> 日期:
> 2018/02/23 09:07
> 主题:
> Re: Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?
>
>
>
> One could write a script and call it in 1 step. I don't believe there is
> anything available OOTB.
>
> Andrew
>
> On Thu, Feb 22, 2018, 7:58 PM  wrote:
>
> >  Thanks a lot for your help.
> >
> > Yes. that is what I do to trigger a dataflow on demand.
> > But I want to know if there is an API that I can do this in one step.
> >
> >
> >
> > 发件人:
> > "Daniel Chaffelson" 
> > 收件人:
> > dev@nifi.apache.org
> > 日期:
> > 2018/02/23 04:46
> > 主题:
> > Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?
> >
> >
> >
> > Hi Boying,
> >
> > I have been working on a NiFi Python Client SDK that might help you
> here,
> > as the goal is to be able to replicate everyday actions taken in the
> NiFi
> > GUI as well as extending it for CICD/SDLC work.
> > For example with the following commands you would:
> >
> >1. get the reference object for a processor
> >2. stop it if it is running
> >3. change the scheduling period to 3s (or most other parameters)
> >4. start it again
> >
> >
> > import nipyapi
> > processor_state_1 = nipyapi.canvas.get_processor('MyProcessor')
> > nipyapi.canvas.schedule_processor(processor, scheduled=False)
> > update = nipyapi.nifi.ProcessorConfigDTO(
> > scheduling_period='3s'
> > )
> > processor_state_2 = nipyapi.canvas.update_processor(processor, update)
> > nipyapi.canvas.schedule_processor(processor, scheduled=True)
> >
> > If you need a different set of steps then please let me know and perhaps
> I
> > can help.
> > Those commands are currently in the master branch awaiting release:
> > https://github.com/Chaffelson/nipyapi
> >
> > Thanks,
> > Dan
> >
> > On Thu, Feb 22, 2018 at 7:41 AM  wrote:
> >
> > > Thanks very much, I'll try your suggestions.
> > >
> > >
> > >
> > > 发件人:
> > > James Wing 
> > > 收件人:
> > > NiFi Dev List 
> > > 日期:
> > > 2018/02/22 14:05
> > > 主题:
> > > Re: 答复: Re: Is there a REST API to run a dataflow on demand?
> > >
> > >
> > >
> > > The NiFi API can be used to start and stop processors or process
> groups,
> > > and this might solve your use case.  But NiFi does not have an API to
> > run
> > > a
> > > processor only once, immediately, separate from its configured
> schedule.
> > I
> > > have solved similar problems in the past by creating two separate
> > upstream
> > > sources - one for scheduled operation, and one for ad-hoc operation.
> > > GenerateFlowFile, GetFile, or similar processors can be used to inject
> a
> > > flowfile where you need to kick off the flow.
> > >
> > > Thanks,
> > >
> > > James
> > >
> > > On Wed, Feb 21, 2018 at 5:57 PM,  wrote:
> > >
> > > > Thanks a lot.
> > > >
> > > > But I want to know if there is a REST API that triggers a dataflow
> on
> > > > demand?
> > > > I don't find the API in the page.
> > > >
> > > >
> > > >
> > > >
> > > > 发件人:
> > > > Charlie Meyer 
> > > > 收件人:
> > > > dev@nifi.apache.org
> > > > 日期:
> > > > 2018/02/22 09:36
> > > > 主题:
> > > > Re: Is there a REST API to run a dataflow on demand?
> > > >
> > > >
> > > >
> > > > Yep, when you make the changes in the UI, open developer tools in
> your
> > > > browser and see what calls to the nifi api it is making then mimic
> > those
> > > > with code.
> > > >
> > > > The nifi team also kindly publishes
> > > > https://nifi.apache.org/docs/nifi-docs/rest-api/index.html which
> help
> > a
> > > > lot.
> > > >
> > > > Best of luck!
> > > >
> > > > -Charlie
> > > >
> > > > On Wed, Feb 21, 2018 at 7:34 PM,  wrote:
> > > >
> > > > > Hi, team,
> > > > >
> > > > > We set up several NiFi dataflows for data processing.
> > > > > These dataflows are configured to run once per day in the
> midnight.
> > > > >
> > > > > But sometimes, some dataflows are failed,I want to run the
> dataflow
> > > > again
> > > > > immediately after fixing the issue instead of waiting for running
> it
> > > in
> > > > > the midnight to
> > > > > make sure that the issue is really fixed.
> > > > >
> > > > > The only way I know to do this is to change the time of running
> the
> > > > > dataflow to the 5 mintutes from now for example
> > > > > and then change it back to midnight.
> > > > >
> > > > > It's a little inconvenient.
> > > > >
> > > > > Is there any REST API that I can use to trigger the dataflow on
> > demand
> > > > > i.e. without change the time back and forth?
> > > > >
> > > > > Thanks
> 

答复: Re: Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?

[luby]

Yes, that is what I do currently.

But I think it will be better if NiFi can support this feature natively.



发件人: 
"Andrew Grande" 
收件人:
dev@nifi.apache.org
日期:
2018/02/23 09:07
主题:
Re: Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?



One could write a script and call it in 1 step. I don't believe there is
anything available OOTB.

Andrew

On Thu, Feb 22, 2018, 7:58 PM  wrote:

>  Thanks a lot for your help.
>
> Yes. that is what I do to trigger a dataflow on demand.
> But I want to know if there is an API that I can do this in one step.
>
>
>
> 发件人:
> "Daniel Chaffelson" 
> 收件人:
> dev@nifi.apache.org
> 日期:
> 2018/02/23 04:46
> 主题:
> Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?
>
>
>
> Hi Boying,
>
> I have been working on a NiFi Python Client SDK that might help you 
here,
> as the goal is to be able to replicate everyday actions taken in the 
NiFi
> GUI as well as extending it for CICD/SDLC work.
> For example with the following commands you would:
>
>1. get the reference object for a processor
>2. stop it if it is running
>3. change the scheduling period to 3s (or most other parameters)
>4. start it again
>
>
> import nipyapi
> processor_state_1 = nipyapi.canvas.get_processor('MyProcessor')
> nipyapi.canvas.schedule_processor(processor, scheduled=False)
> update = nipyapi.nifi.ProcessorConfigDTO(
> scheduling_period='3s'
> )
> processor_state_2 = nipyapi.canvas.update_processor(processor, update)
> nipyapi.canvas.schedule_processor(processor, scheduled=True)
>
> If you need a different set of steps then please let me know and perhaps 
I
> can help.
> Those commands are currently in the master branch awaiting release:
> https://github.com/Chaffelson/nipyapi
>
> Thanks,
> Dan
>
> On Thu, Feb 22, 2018 at 7:41 AM  wrote:
>
> > Thanks very much, I'll try your suggestions.
> >
> >
> >
> > 发件人:
> > James Wing 
> > 收件人:
> > NiFi Dev List 
> > 日期:
> > 2018/02/22 14:05
> > 主题:
> > Re: 答复: Re: Is there a REST API to run a dataflow on demand?
> >
> >
> >
> > The NiFi API can be used to start and stop processors or process 
groups,
> > and this might solve your use case.  But NiFi does not have an API to
> run
> > a
> > processor only once, immediately, separate from its configured 
schedule.
> I
> > have solved similar problems in the past by creating two separate
> upstream
> > sources - one for scheduled operation, and one for ad-hoc operation.
> > GenerateFlowFile, GetFile, or similar processors can be used to inject 
a
> > flowfile where you need to kick off the flow.
> >
> > Thanks,
> >
> > James
> >
> > On Wed, Feb 21, 2018 at 5:57 PM,  wrote:
> >
> > > Thanks a lot.
> > >
> > > But I want to know if there is a REST API that triggers a dataflow 
on
> > > demand?
> > > I don't find the API in the page.
> > >
> > >
> > >
> > >
> > > 发件人:
> > > Charlie Meyer 
> > > 收件人:
> > > dev@nifi.apache.org
> > > 日期:
> > > 2018/02/22 09:36
> > > 主题:
> > > Re: Is there a REST API to run a dataflow on demand?
> > >
> > >
> > >
> > > Yep, when you make the changes in the UI, open developer tools in 
your
> > > browser and see what calls to the nifi api it is making then mimic
> those
> > > with code.
> > >
> > > The nifi team also kindly publishes
> > > https://nifi.apache.org/docs/nifi-docs/rest-api/index.html which 
help
> a
> > > lot.
> > >
> > > Best of luck!
> > >
> > > -Charlie
> > >
> > > On Wed, Feb 21, 2018 at 7:34 PM,  wrote:
> > >
> > > > Hi, team,
> > > >
> > > > We set up several NiFi dataflows for data processing.
> > > > These dataflows are configured to run once per day in the 
midnight.
> > > >
> > > > But sometimes, some dataflows are failed,I want to run the 
dataflow
> > > again
> > > > immediately after fixing the issue instead of waiting for running 
it
> > in
> > > > the midnight to
> > > > make sure that the issue is really fixed.
> > > >
> > > > The only way I know to do this is to change the time of running 
the
> > > > dataflow to the 5 mintutes from now for example
> > > > and then change it back to midnight.
> > > >
> > > > It's a little inconvenient.
> > > >
> > > > Is there any REST API that I can use to trigger the dataflow on
> demand
> > > > i.e. without change the time back and forth?
> > > >
> > > > Thanks
> > > >
> > > > Boying
> > > >
> > > >
> > > >
> > > > 本邮件内容包含保密信息。如阁下并非拟发送的收件人，请您不要阅读、保
存
> 、
> > 对
> > > 外
> > > > 披露或复制本邮件的任何内容，或者打开本邮件的任何附件。请即回复邮件
告
> 知
> > 发
> > > 件
> > > > 人，并立刻将该邮件及其附件从您的电脑系统中全部删除，不胜感激。
> > > >
> > > >
> > > > This email message may contain confidential and/or privileged
> > > information.
> > > > If you are not the intended recipient, please do not read, save,
> > > forward,
> > > > disclose or copy the contents of this email or open any file
> attached
> > to
> > > > this email. We will be grateful if you 

Re: Facing issue in Site to Site Https Communication

[Koji Kawamura]

Hi,

A common mistake with tls-toolkit is generating keystore and
truststore for each node using DIFFERENT NiFi CA Cert.
If tls-toolkit standalone is executed against different output
directories, it may produce different NiFi CA in each directory.

Please check both of s2s client and server truststores have the same
NiFi CA Cert.
To do so, use keytool command:
keytool -list -keystore truststore.jks
nifi-cert, Feb 9, 2018, trustedCertEntry,
Certificate fingerprint (SHA1):
FE:0D:FE:0D:72:40:0A:7E:49:45:1B:78:D9:F5:F4:6E:A2:3C:92:E5

If that's not the case, then I'd recommend adding
-Djavax.net.debug=all Java option to debug further.
You can add Java options from ${NIFI_HOME}/conf/bootstrap.conf.
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html

Thanks,
Koji

On Fri, Feb 23, 2018 at 9:01 AM, yi  wrote:
> Apologies, I should clarify that I still do not have communication working
> site to site. Please assist. Thank you.
>
>
>
> --
> Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/

Re: Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?

[Andrew Grande]

One could write a script and call it in 1 step. I don't believe there is
anything available OOTB.

Andrew

On Thu, Feb 22, 2018, 7:58 PM  wrote:

>  Thanks a lot for your help.
>
> Yes. that is what I do to trigger a dataflow on demand.
> But I want to know if there is an API that I can do this in one step.
>
>
>
> 发件人:
> "Daniel Chaffelson" 
> 收件人:
> dev@nifi.apache.org
> 日期:
> 2018/02/23 04:46
> 主题:
> Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?
>
>
>
> Hi Boying,
>
> I have been working on a NiFi Python Client SDK that might help you here,
> as the goal is to be able to replicate everyday actions taken in the NiFi
> GUI as well as extending it for CICD/SDLC work.
> For example with the following commands you would:
>
>1. get the reference object for a processor
>2. stop it if it is running
>3. change the scheduling period to 3s (or most other parameters)
>4. start it again
>
>
> import nipyapi
> processor_state_1 = nipyapi.canvas.get_processor('MyProcessor')
> nipyapi.canvas.schedule_processor(processor, scheduled=False)
> update = nipyapi.nifi.ProcessorConfigDTO(
> scheduling_period='3s'
> )
> processor_state_2 = nipyapi.canvas.update_processor(processor, update)
> nipyapi.canvas.schedule_processor(processor, scheduled=True)
>
> If you need a different set of steps then please let me know and perhaps I
> can help.
> Those commands are currently in the master branch awaiting release:
> https://github.com/Chaffelson/nipyapi
>
> Thanks,
> Dan
>
> On Thu, Feb 22, 2018 at 7:41 AM  wrote:
>
> > Thanks very much, I'll try your suggestions.
> >
> >
> >
> > 发件人:
> > James Wing 
> > 收件人:
> > NiFi Dev List 
> > 日期:
> > 2018/02/22 14:05
> > 主题:
> > Re: 答复: Re: Is there a REST API to run a dataflow on demand?
> >
> >
> >
> > The NiFi API can be used to start and stop processors or process groups,
> > and this might solve your use case.  But NiFi does not have an API to
> run
> > a
> > processor only once, immediately, separate from its configured schedule.
> I
> > have solved similar problems in the past by creating two separate
> upstream
> > sources - one for scheduled operation, and one for ad-hoc operation.
> > GenerateFlowFile, GetFile, or similar processors can be used to inject a
> > flowfile where you need to kick off the flow.
> >
> > Thanks,
> >
> > James
> >
> > On Wed, Feb 21, 2018 at 5:57 PM,  wrote:
> >
> > > Thanks a lot.
> > >
> > > But I want to know if there is a REST API that triggers a dataflow on
> > > demand?
> > > I don't find the API in the page.
> > >
> > >
> > >
> > >
> > > 发件人:
> > > Charlie Meyer 
> > > 收件人:
> > > dev@nifi.apache.org
> > > 日期:
> > > 2018/02/22 09:36
> > > 主题:
> > > Re: Is there a REST API to run a dataflow on demand?
> > >
> > >
> > >
> > > Yep, when you make the changes in the UI, open developer tools in your
> > > browser and see what calls to the nifi api it is making then mimic
> those
> > > with code.
> > >
> > > The nifi team also kindly publishes
> > > https://nifi.apache.org/docs/nifi-docs/rest-api/index.html which help
> a
> > > lot.
> > >
> > > Best of luck!
> > >
> > > -Charlie
> > >
> > > On Wed, Feb 21, 2018 at 7:34 PM,  wrote:
> > >
> > > > Hi, team,
> > > >
> > > > We set up several NiFi dataflows for data processing.
> > > > These dataflows are configured to run once per day in the midnight.
> > > >
> > > > But sometimes, some dataflows are failed,I want to run the dataflow
> > > again
> > > > immediately after fixing the issue instead of waiting for running it
> > in
> > > > the midnight to
> > > > make sure that the issue is really fixed.
> > > >
> > > > The only way I know to do this is to change the time of running the
> > > > dataflow to the 5 mintutes from now for example
> > > > and then change it back to midnight.
> > > >
> > > > It's a little inconvenient.
> > > >
> > > > Is there any REST API that I can use to trigger the dataflow on
> demand
> > > > i.e. without change the time back and forth?
> > > >
> > > > Thanks
> > > >
> > > > Boying
> > > >
> > > >
> > > >
> > > > 本邮件内容包含保密信息。如阁下并非拟发送的收件人，请您不要阅读、保存
> 、
> > 对
> > > 外
> > > > 披露或复制本邮件的任何内容，或者打开本邮件的任何附件。请即回复邮件告
> 知
> > 发
> > > 件
> > > > 人，并立刻将该邮件及其附件从您的电脑系统中全部删除，不胜感激。
> > > >
> > > >
> > > > This email message may contain confidential and/or privileged
> > > information.
> > > > If you are not the intended recipient, please do not read, save,
> > > forward,
> > > > disclose or copy the contents of this email or open any file
> attached
> > to
> > > > this email. We will be grateful if you could advise the sender
> > > immediately
> > > > by replying this email, and delete this email and any attachment or
> > > links
> > > > to this email completely and immediately from your computer system.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 

Re: Facing issue in Site to Site Https Communication

[yi]

Apologies, I should clarify that I still do not have communication working
site to site. Please assist. Thank you.



--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/

Re: Re: 答复: Re: Is there a REST API to run a dataflow on demand?

[Daniel Chaffelson]

Hi Boying,

I have been working on a NiFi Python Client SDK that might help you here,
as the goal is to be able to replicate everyday actions taken in the NiFi
GUI as well as extending it for CICD/SDLC work.
For example with the following commands you would:

   1. get the reference object for a processor
   2. stop it if it is running
   3. change the scheduling period to 3s (or most other parameters)
   4. start it again


import nipyapi
processor_state_1 = nipyapi.canvas.get_processor('MyProcessor')
nipyapi.canvas.schedule_processor(processor, scheduled=False)
update = nipyapi.nifi.ProcessorConfigDTO(
scheduling_period='3s'
)
processor_state_2 = nipyapi.canvas.update_processor(processor, update)
nipyapi.canvas.schedule_processor(processor, scheduled=True)

If you need a different set of steps then please let me know and perhaps I
can help.
Those commands are currently in the master branch awaiting release:
https://github.com/Chaffelson/nipyapi

Thanks,
Dan

On Thu, Feb 22, 2018 at 7:41 AM  wrote:

> Thanks very much, I'll try your suggestions.
>
>
>
> 发件人:
> James Wing 
> 收件人:
> NiFi Dev List 
> 日期:
> 2018/02/22 14:05
> 主题:
> Re: 答复: Re: Is there a REST API to run a dataflow on demand?
>
>
>
> The NiFi API can be used to start and stop processors or process groups,
> and this might solve your use case.  But NiFi does not have an API to run
> a
> processor only once, immediately, separate from its configured schedule. I
> have solved similar problems in the past by creating two separate upstream
> sources - one for scheduled operation, and one for ad-hoc operation.
> GenerateFlowFile, GetFile, or similar processors can be used to inject a
> flowfile where you need to kick off the flow.
>
> Thanks,
>
> James
>
> On Wed, Feb 21, 2018 at 5:57 PM,  wrote:
>
> > Thanks a lot.
> >
> > But I want to know if there is a REST API that triggers a dataflow on
> > demand?
> > I don't find the API in the page.
> >
> >
> >
> >
> > 发件人:
> > Charlie Meyer 
> > 收件人:
> > dev@nifi.apache.org
> > 日期:
> > 2018/02/22 09:36
> > 主题:
> > Re: Is there a REST API to run a dataflow on demand?
> >
> >
> >
> > Yep, when you make the changes in the UI, open developer tools in your
> > browser and see what calls to the nifi api it is making then mimic those
> > with code.
> >
> > The nifi team also kindly publishes
> > https://nifi.apache.org/docs/nifi-docs/rest-api/index.html which help a
> > lot.
> >
> > Best of luck!
> >
> > -Charlie
> >
> > On Wed, Feb 21, 2018 at 7:34 PM,  wrote:
> >
> > > Hi, team,
> > >
> > > We set up several NiFi dataflows for data processing.
> > > These dataflows are configured to run once per day in the midnight.
> > >
> > > But sometimes, some dataflows are failed,I want to run the dataflow
> > again
> > > immediately after fixing the issue instead of waiting for running it
> in
> > > the midnight to
> > > make sure that the issue is really fixed.
> > >
> > > The only way I know to do this is to change the time of running the
> > > dataflow to the 5 mintutes from now for example
> > > and then change it back to midnight.
> > >
> > > It's a little inconvenient.
> > >
> > > Is there any REST API that I can use to trigger the dataflow on demand
> > > i.e. without change the time back and forth?
> > >
> > > Thanks
> > >
> > > Boying
> > >
> > >
> > >
> > > 本邮件内容包含保密信息。如阁下并非拟发送的收件人，请您不要阅读、保存、
> 对
> > 外
> > > 披露或复制本邮件的任何内容，或者打开本邮件的任何附件。请即回复邮件告知
> 发
> > 件
> > > 人，并立刻将该邮件及其附件从您的电脑系统中全部删除，不胜感激。
> > >
> > >
> > > This email message may contain confidential and/or privileged
> > information.
> > > If you are not the intended recipient, please do not read, save,
> > forward,
> > > disclose or copy the contents of this email or open any file attached
> to
> > > this email. We will be grateful if you could advise the sender
> > immediately
> > > by replying this email, and delete this email and any attachment or
> > links
> > > to this email completely and immediately from your computer system.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> > 本邮件内容包含保密信息。如阁下并非拟发送的收件人，请您不要阅读、保存、对
> 外
> > 披露或复制本邮件的任何内容，或者打开本邮件的任何附件。请即回复邮件告知发
> 件
> > 人，并立刻将该邮件及其附件从您的电脑系统中全部删除，不胜感激。
> >
> >
> > This email message may contain confidential and/or privileged
> information.
> > If you are not the intended recipient, please do not read, save,
> forward,
> > disclose or copy the contents of this email or open any file attached to
> > this email. We will be grateful if you could advise the sender
> immediately
> > by replying this email, and delete this email and any attachment or
> links
> > to this email completely and immediately from your computer system.
> >
> >
> >
> >
>
>
>
>
>
>
> 本邮件内容包含保密信息。如阁下并非拟发送的收件人，请您不要阅读、保存、对外
> 披露或复制本邮件的任何内容，或者打开本邮件的任何附件。请即回复邮件告知发件
> 人，并立刻将该邮件及其附件从您的电脑系统中全部删除，不胜感激。
>
>
> This email message may contain confidential and/or privileged information.
> If you are not the 

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Scott Aslan]

Joe P,

Apache Cordova has a sub-project that is used by the top-level and other
sub-projects: https://github.com/apache/cordova-lib

-Scotty

On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall 
wrote:

> Scott,
>
> Definitely like the direction of standardizing NiFi and Registry around the
> same set of components, so the user has a common UX. Is there precedent for
> creating a new sub-project just for common components/modules to be used by
> the top-level, and it's other sub-projects? My concerns are similar to
> Joe's. Along those lines, if the core problems we're trying to address is
> the release process and distribution, is there a less "heavy-weight"
> avenue?
>
> In the past, we've also talked about pulling out the core NiFi framework to
> be shared between NiFi and MiNiFi-Java for similar reasons. How we go about
> solving this for the UI could be used a model for the core framework as
> well.
>
> - Joe
>
> On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen 
> wrote:
>
> > Also, what sort of framework is the UI being standardized on? Angular?
> > React? Something else?
> >
> > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:
> >
> > > Scott
> > >
> > > Ok so extract out the fluid design work you started with NiFi Registry
> > > to its own codebase which can be rev'd and published to NPM making it
> > > easier to consume/reuse across NiFi projects and offers better
> > > consistency.  This sounds interesting.
> > >
> > > In thinking through the additional community effort or the effort
> > > trade-off:
> > > How often do you anticipate we'd be doing releases (and thus
> > > validation/voting) for this?
> > > How often would those differ from when we'd want to do a NiFi or NiFi
> > > Registry release?
> > > How do you envision the community would be able to help vet/validate
> > > releases of these modules?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> > > wrote:
> > > > NiFi Community,
> > > >
> > > > I'd like to initiate a discussion around creating a sub-project of
> NiFi
> > > to
> > > > encompass the Fluid Design System NgModule created during the
> > development
> > > > of the NiFi Registry. A possible name for this sub-project is simply
> > > > "NiFi Fluid
> > > > Design System". The idea would be to create a sub-project that
> > > distributes
> > > > an atomic set of high quality, reuse-able, theme-able, and testable
> > UI/UX
> > > > components, fonts, and other JS modules for use across the various
> web
> > > > applications throughout the NiFi universe (uNiFiverse???). Both NiFi
> > and
> > > > NiFi Registry web applications would eventually leverage this module
> > via
> > > > npm. This approach will enable us to provide our users with a
> > consistent
> > > > experience across web applications. Creating a sub-project would also
> > > allow
> > > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > > released
> > > > on it's own timeline. In addition, it would make tracking issues/work
> > > much
> > > > clearer through a separate JIRA.
> > > >
> > > > Please discuss and provide and thoughts or feedback.
> > > >
> > > > Thanks,
> > > >
> > > > Scotty
> > >
> >
>
>
>
> --
> *Joe Percivall*
> linkedin.com/in/Percivall
> e: jperciv...@apache.com
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Michael Moser]

 There are compelling pros and easily identifiable cons to placing UI
components into their own project.  I don't have anything to add there.

Please, however, consider a different name.  "Fluid Design System" is
generic to the point of giving no cognitive clue about what it actually
is.  And without that clue, it's no different than a shorter made-up word.
Also, a quick Google search doesn't indicate that it's an industry accepted
phrase that conveys meaning.

Consider:

Fluidifi
NiFi Fluid UI
NiFi UI Components
NiFi FDS

Thanks,
-- Mike


On Thu, Feb 22, 2018 at 1:43 PM, Scott Aslan  wrote:

> Joe,
>
> Yes, extract out the FDS.
>
> As for a release schedule, I don't think there would need to be one. We
> would put out new releases as needed for new features or components. These
> releases would be totally independent of NiFi or NiFi Registry. The
> intention with this project is to follow semantic versioning and avoid
> making breaking changes so using this library in NiFi or the NiFi Registry
> would be as simple as updating the version number in the package.json and
> rebuilding the application.
>
> As for validation of releases I have a couple of ideas. I envisioned this
> code base would follow a RTC paradigm and the initial release of this FDS
> NgModule would include unit test coverage of all the existing
> features/components/utils. Any new features/components/utils would require
> adequate test coverage before being merged to NiFi FDS master. We could
> also provide a demo application that users can build and deploy locally to
> allow for human verification or even e2e testing...
>
> I took the liberty of standing up a repo to give everyone a better idea of
> what we are all talking about.
> https://github.com/scottyaslan/fluid-design-system
>
> Since no server or backend is required to run these UI/UX components I also
> stood a demo of this as a github.io page here:
> https://scottyaslan.github.io/fluid-design-system/
> 
>
> -Scotty
>
> On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:
>
> > Scott
> >
> > Ok so extract out the fluid design work you started with NiFi Registry
> > to its own codebase which can be rev'd and published to NPM making it
> > easier to consume/reuse across NiFi projects and offers better
> > consistency.  This sounds interesting.
> >
> > In thinking through the additional community effort or the effort
> > trade-off:
> > How often do you anticipate we'd be doing releases (and thus
> > validation/voting) for this?
> > How often would those differ from when we'd want to do a NiFi or NiFi
> > Registry release?
> > How do you envision the community would be able to help vet/validate
> > releases of these modules?
> >
> > Thanks
> > Joe
> >
> > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> > wrote:
> > > NiFi Community,
> > >
> > > I'd like to initiate a discussion around creating a sub-project of NiFi
> > to
> > > encompass the Fluid Design System NgModule created during the
> development
> > > of the NiFi Registry. A possible name for this sub-project is simply
> > > "NiFi Fluid
> > > Design System". The idea would be to create a sub-project that
> > distributes
> > > an atomic set of high quality, reuse-able, theme-able, and testable
> UI/UX
> > > components, fonts, and other JS modules for use across the various web
> > > applications throughout the NiFi universe (uNiFiverse???). Both NiFi
> and
> > > NiFi Registry web applications would eventually leverage this module
> via
> > > npm. This approach will enable us to provide our users with a
> consistent
> > > experience across web applications. Creating a sub-project would also
> > allow
> > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > released
> > > on it's own timeline. In addition, it would make tracking issues/work
> > much
> > > clearer through a separate JIRA.
> > >
> > > Please discuss and provide and thoughts or feedback.
> > >
> > > Thanks,
> > >
> > > Scotty
> >
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Scott Aslan]

Joe,

Yes, extract out the FDS.

As for a release schedule, I don't think there would need to be one. We
would put out new releases as needed for new features or components. These
releases would be totally independent of NiFi or NiFi Registry. The
intention with this project is to follow semantic versioning and avoid
making breaking changes so using this library in NiFi or the NiFi Registry
would be as simple as updating the version number in the package.json and
rebuilding the application.

As for validation of releases I have a couple of ideas. I envisioned this
code base would follow a RTC paradigm and the initial release of this FDS
NgModule would include unit test coverage of all the existing
features/components/utils. Any new features/components/utils would require
adequate test coverage before being merged to NiFi FDS master. We could
also provide a demo application that users can build and deploy locally to
allow for human verification or even e2e testing...

I took the liberty of standing up a repo to give everyone a better idea of
what we are all talking about.
https://github.com/scottyaslan/fluid-design-system

Since no server or backend is required to run these UI/UX components I also
stood a demo of this as a github.io page here:
https://scottyaslan.github.io/fluid-design-system/


-Scotty

On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:

> Scott
>
> Ok so extract out the fluid design work you started with NiFi Registry
> to its own codebase which can be rev'd and published to NPM making it
> easier to consume/reuse across NiFi projects and offers better
> consistency.  This sounds interesting.
>
> In thinking through the additional community effort or the effort
> trade-off:
> How often do you anticipate we'd be doing releases (and thus
> validation/voting) for this?
> How often would those differ from when we'd want to do a NiFi or NiFi
> Registry release?
> How do you envision the community would be able to help vet/validate
> releases of these modules?
>
> Thanks
> Joe
>
> On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> wrote:
> > NiFi Community,
> >
> > I'd like to initiate a discussion around creating a sub-project of NiFi
> to
> > encompass the Fluid Design System NgModule created during the development
> > of the NiFi Registry. A possible name for this sub-project is simply
> > "NiFi Fluid
> > Design System". The idea would be to create a sub-project that
> distributes
> > an atomic set of high quality, reuse-able, theme-able, and testable UI/UX
> > components, fonts, and other JS modules for use across the various web
> > applications throughout the NiFi universe (uNiFiverse???). Both NiFi and
> > NiFi Registry web applications would eventually leverage this module via
> > npm. This approach will enable us to provide our users with a consistent
> > experience across web applications. Creating a sub-project would also
> allow
> > the FDS code to evolve independently of NiFi/NiFi registry and be
> released
> > on it's own timeline. In addition, it would make tracking issues/work
> much
> > clearer through a separate JIRA.
> >
> > Please discuss and provide and thoughts or feedback.
> >
> > Thanks,
> >
> > Scotty
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Sivaprasanna]

I agree with Matt. With clear documentation and guides, contributions on
the sub-projects can be streamlined and be ensured that the necessary
changes are already available on the core project i.e NiFi. One challenge
is that the committer of the sub-project should have the courtesy to check
wether the supporting changes are made available to the core project and
track its status but given how contributions are being handled in
nifi-registry project, I don’t think it’s going to be that much of a
headache.

We could also add to the helper doc mentioning that if the contribution is
going to affect a core component, the contributor needs to add the JIRA id
of the core project’s supporting changes in the sub-projects’ issue
description.

On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman 
wrote:

> Joe, Joe,
>
> Regarding the release process... I think it could be similar to how folks
> verified and validated the NiFi Registry release. Guidance was given in a
> helper guide regarding how to obtain/build a branch or PR that references
> the new components. For the Registry release, there was a PR for NiFi that
> had the supporting changes already available.
>
> We may have this issue any time we release new versions that depend on
> another (sub)project.
>
> Matt
>
> On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall 
> wrote:
>
> > Scott,
> >
> > Definitely like the direction of standardizing NiFi and Registry around
> the
> > same set of components, so the user has a common UX. Is there precedent
> for
> > creating a new sub-project just for common components/modules to be used
> by
> > the top-level, and it's other sub-projects? My concerns are similar to
> > Joe's. Along those lines, if the core problems we're trying to address is
> > the release process and distribution, is there a less "heavy-weight"
> > avenue?
> >
> > In the past, we've also talked about pulling out the core NiFi framework
> to
> > be shared between NiFi and MiNiFi-Java for similar reasons. How we go
> about
> > solving this for the UI could be used a model for the core framework as
> > well.
> >
> > - Joe
> >
> > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen 
> > wrote:
> >
> > > Also, what sort of framework is the UI being standardized on? Angular?
> > > React? Something else?
> > >
> > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:
> > >
> > > > Scott
> > > >
> > > > Ok so extract out the fluid design work you started with NiFi
> Registry
> > > > to its own codebase which can be rev'd and published to NPM making it
> > > > easier to consume/reuse across NiFi projects and offers better
> > > > consistency.  This sounds interesting.
> > > >
> > > > In thinking through the additional community effort or the effort
> > > > trade-off:
> > > > How often do you anticipate we'd be doing releases (and thus
> > > > validation/voting) for this?
> > > > How often would those differ from when we'd want to do a NiFi or NiFi
> > > > Registry release?
> > > > How do you envision the community would be able to help vet/validate
> > > > releases of these modules?
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> > > > wrote:
> > > > > NiFi Community,
> > > > >
> > > > > I'd like to initiate a discussion around creating a sub-project of
> > NiFi
> > > > to
> > > > > encompass the Fluid Design System NgModule created during the
> > > development
> > > > > of the NiFi Registry. A possible name for this sub-project is
> simply
> > > > > "NiFi Fluid
> > > > > Design System". The idea would be to create a sub-project that
> > > > distributes
> > > > > an atomic set of high quality, reuse-able, theme-able, and testable
> > > UI/UX
> > > > > components, fonts, and other JS modules for use across the various
> > web
> > > > > applications throughout the NiFi universe (uNiFiverse???). Both
> NiFi
> > > and
> > > > > NiFi Registry web applications would eventually leverage this
> module
> > > via
> > > > > npm. This approach will enable us to provide our users with a
> > > consistent
> > > > > experience across web applications. Creating a sub-project would
> also
> > > > allow
> > > > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > > > released
> > > > > on it's own timeline. In addition, it would make tracking
> issues/work
> > > > much
> > > > > clearer through a separate JIRA.
> > > > >
> > > > > Please discuss and provide and thoughts or feedback.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Scotty
> > > >
> > >
> >
> >
> >
> > --
> > *Joe Percivall*
> > linkedin.com/in/Percivall
> > e: jperciv...@apache.com
> >
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Matt Gilman]

Joe, Joe,

Regarding the release process... I think it could be similar to how folks
verified and validated the NiFi Registry release. Guidance was given in a
helper guide regarding how to obtain/build a branch or PR that references
the new components. For the Registry release, there was a PR for NiFi that
had the supporting changes already available.

We may have this issue any time we release new versions that depend on
another (sub)project.

Matt

On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall 
wrote:

> Scott,
>
> Definitely like the direction of standardizing NiFi and Registry around the
> same set of components, so the user has a common UX. Is there precedent for
> creating a new sub-project just for common components/modules to be used by
> the top-level, and it's other sub-projects? My concerns are similar to
> Joe's. Along those lines, if the core problems we're trying to address is
> the release process and distribution, is there a less "heavy-weight"
> avenue?
>
> In the past, we've also talked about pulling out the core NiFi framework to
> be shared between NiFi and MiNiFi-Java for similar reasons. How we go about
> solving this for the UI could be used a model for the core framework as
> well.
>
> - Joe
>
> On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen 
> wrote:
>
> > Also, what sort of framework is the UI being standardized on? Angular?
> > React? Something else?
> >
> > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:
> >
> > > Scott
> > >
> > > Ok so extract out the fluid design work you started with NiFi Registry
> > > to its own codebase which can be rev'd and published to NPM making it
> > > easier to consume/reuse across NiFi projects and offers better
> > > consistency.  This sounds interesting.
> > >
> > > In thinking through the additional community effort or the effort
> > > trade-off:
> > > How often do you anticipate we'd be doing releases (and thus
> > > validation/voting) for this?
> > > How often would those differ from when we'd want to do a NiFi or NiFi
> > > Registry release?
> > > How do you envision the community would be able to help vet/validate
> > > releases of these modules?
> > >
> > > Thanks
> > > Joe
> > >
> > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> > > wrote:
> > > > NiFi Community,
> > > >
> > > > I'd like to initiate a discussion around creating a sub-project of
> NiFi
> > > to
> > > > encompass the Fluid Design System NgModule created during the
> > development
> > > > of the NiFi Registry. A possible name for this sub-project is simply
> > > > "NiFi Fluid
> > > > Design System". The idea would be to create a sub-project that
> > > distributes
> > > > an atomic set of high quality, reuse-able, theme-able, and testable
> > UI/UX
> > > > components, fonts, and other JS modules for use across the various
> web
> > > > applications throughout the NiFi universe (uNiFiverse???). Both NiFi
> > and
> > > > NiFi Registry web applications would eventually leverage this module
> > via
> > > > npm. This approach will enable us to provide our users with a
> > consistent
> > > > experience across web applications. Creating a sub-project would also
> > > allow
> > > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > > released
> > > > on it's own timeline. In addition, it would make tracking issues/work
> > > much
> > > > clearer through a separate JIRA.
> > > >
> > > > Please discuss and provide and thoughts or feedback.
> > > >
> > > > Thanks,
> > > >
> > > > Scotty
> > >
> >
>
>
>
> --
> *Joe Percivall*
> linkedin.com/in/Percivall
> e: jperciv...@apache.com
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Joe Percivall]

Scott,

Definitely like the direction of standardizing NiFi and Registry around the
same set of components, so the user has a common UX. Is there precedent for
creating a new sub-project just for common components/modules to be used by
the top-level, and it's other sub-projects? My concerns are similar to
Joe's. Along those lines, if the core problems we're trying to address is
the release process and distribution, is there a less "heavy-weight" avenue?

In the past, we've also talked about pulling out the core NiFi framework to
be shared between NiFi and MiNiFi-Java for similar reasons. How we go about
solving this for the UI could be used a model for the core framework as
well.

- Joe

On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen 
wrote:

> Also, what sort of framework is the UI being standardized on? Angular?
> React? Something else?
>
> On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:
>
> > Scott
> >
> > Ok so extract out the fluid design work you started with NiFi Registry
> > to its own codebase which can be rev'd and published to NPM making it
> > easier to consume/reuse across NiFi projects and offers better
> > consistency.  This sounds interesting.
> >
> > In thinking through the additional community effort or the effort
> > trade-off:
> > How often do you anticipate we'd be doing releases (and thus
> > validation/voting) for this?
> > How often would those differ from when we'd want to do a NiFi or NiFi
> > Registry release?
> > How do you envision the community would be able to help vet/validate
> > releases of these modules?
> >
> > Thanks
> > Joe
> >
> > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> > wrote:
> > > NiFi Community,
> > >
> > > I'd like to initiate a discussion around creating a sub-project of NiFi
> > to
> > > encompass the Fluid Design System NgModule created during the
> development
> > > of the NiFi Registry. A possible name for this sub-project is simply
> > > "NiFi Fluid
> > > Design System". The idea would be to create a sub-project that
> > distributes
> > > an atomic set of high quality, reuse-able, theme-able, and testable
> UI/UX
> > > components, fonts, and other JS modules for use across the various web
> > > applications throughout the NiFi universe (uNiFiverse???). Both NiFi
> and
> > > NiFi Registry web applications would eventually leverage this module
> via
> > > npm. This approach will enable us to provide our users with a
> consistent
> > > experience across web applications. Creating a sub-project would also
> > allow
> > > the FDS code to evolve independently of NiFi/NiFi registry and be
> > released
> > > on it's own timeline. In addition, it would make tracking issues/work
> > much
> > > clearer through a separate JIRA.
> > >
> > > Please discuss and provide and thoughts or feedback.
> > >
> > > Thanks,
> > >
> > > Scotty
> >
>



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

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Mike Thomsen]

Also, what sort of framework is the UI being standardized on? Angular?
React? Something else?

On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt  wrote:

> Scott
>
> Ok so extract out the fluid design work you started with NiFi Registry
> to its own codebase which can be rev'd and published to NPM making it
> easier to consume/reuse across NiFi projects and offers better
> consistency.  This sounds interesting.
>
> In thinking through the additional community effort or the effort
> trade-off:
> How often do you anticipate we'd be doing releases (and thus
> validation/voting) for this?
> How often would those differ from when we'd want to do a NiFi or NiFi
> Registry release?
> How do you envision the community would be able to help vet/validate
> releases of these modules?
>
> Thanks
> Joe
>
> On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan 
> wrote:
> > NiFi Community,
> >
> > I'd like to initiate a discussion around creating a sub-project of NiFi
> to
> > encompass the Fluid Design System NgModule created during the development
> > of the NiFi Registry. A possible name for this sub-project is simply
> > "NiFi Fluid
> > Design System". The idea would be to create a sub-project that
> distributes
> > an atomic set of high quality, reuse-able, theme-able, and testable UI/UX
> > components, fonts, and other JS modules for use across the various web
> > applications throughout the NiFi universe (uNiFiverse???). Both NiFi and
> > NiFi Registry web applications would eventually leverage this module via
> > npm. This approach will enable us to provide our users with a consistent
> > experience across web applications. Creating a sub-project would also
> allow
> > the FDS code to evolve independently of NiFi/NiFi registry and be
> released
> > on it's own timeline. In addition, it would make tracking issues/work
> much
> > clearer through a separate JIRA.
> >
> > Please discuss and provide and thoughts or feedback.
> >
> > Thanks,
> >
> > Scotty
>

Re: [DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Joe Witt]

Scott

Ok so extract out the fluid design work you started with NiFi Registry
to its own codebase which can be rev'd and published to NPM making it
easier to consume/reuse across NiFi projects and offers better
consistency.  This sounds interesting.

In thinking through the additional community effort or the effort trade-off:
How often do you anticipate we'd be doing releases (and thus
validation/voting) for this?
How often would those differ from when we'd want to do a NiFi or NiFi
Registry release?
How do you envision the community would be able to help vet/validate
releases of these modules?

Thanks
Joe

On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan  wrote:
> NiFi Community,
>
> I'd like to initiate a discussion around creating a sub-project of NiFi to
> encompass the Fluid Design System NgModule created during the development
> of the NiFi Registry. A possible name for this sub-project is simply
> "NiFi Fluid
> Design System". The idea would be to create a sub-project that distributes
> an atomic set of high quality, reuse-able, theme-able, and testable UI/UX
> components, fonts, and other JS modules for use across the various web
> applications throughout the NiFi universe (uNiFiverse???). Both NiFi and
> NiFi Registry web applications would eventually leverage this module via
> npm. This approach will enable us to provide our users with a consistent
> experience across web applications. Creating a sub-project would also allow
> the FDS code to evolve independently of NiFi/NiFi registry and be released
> on it's own timeline. In addition, it would make tracking issues/work much
> clearer through a separate JIRA.
>
> Please discuss and provide and thoughts or feedback.
>
> Thanks,
>
> Scotty

[DISCUSS] Proposal for an Apache NiFi sub-project - NiFi Fluid Design System

[Scott Aslan]

NiFi Community,

I'd like to initiate a discussion around creating a sub-project of NiFi to
encompass the Fluid Design System NgModule created during the development
of the NiFi Registry. A possible name for this sub-project is simply
"NiFi Fluid
Design System". The idea would be to create a sub-project that distributes
an atomic set of high quality, reuse-able, theme-able, and testable UI/UX
components, fonts, and other JS modules for use across the various web
applications throughout the NiFi universe (uNiFiverse???). Both NiFi and
NiFi Registry web applications would eventually leverage this module via
npm. This approach will enable us to provide our users with a consistent
experience across web applications. Creating a sub-project would also allow
the FDS code to evolve independently of NiFi/NiFi registry and be released
on it's own timeline. In addition, it would make tracking issues/work much
clearer through a separate JIRA.

Please discuss and provide and thoughts or feedback.

Thanks,

Scotty

Re: Facing issue in Site to Site Https Communication

[yi]

Hi Koji,

Thanks for the very quick response.

The toolkit does generate a nifi.properties file for each of the servers.

I've modified it slightly for things like port numbers, but the
keystore/truststore settings I am pretty confident about, as I have had
success with accessing the nifi UI. I imported the .p12 certificates that
the toolkit produced to my browser.

RPG side:

nifi.security.keystore=./conf/keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=
nifi.security.needClientAuth=
nifi.security.user.authorizer=managed-authorizer
nifi.security.user.login.identity.provider=
nifi.security.ocsp.responder.url=
nifi.security.ocsp.responder.certificate=

"server" side:

nifi.security.keystore=./conf/keystore.jks
nifi.security.keystoreType=jks
nifi.security.keystorePasswd=
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks
nifi.security.truststoreType=jks
nifi.security.truststorePasswd=
nifi.security.needClientAuth=
nifi.security.user.authorizer=managed-authorizer
nifi.security.user.login.identity.provider=
nifi.security.ocsp.responder.url=
nifi.security.ocsp.responder.certificate=

Thank you



--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/