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 imp
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-pr
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 eff
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
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 sim
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 N
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
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 v
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 witho
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
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 pr
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/
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
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
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 trusts
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 s
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.
>
>
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
Regist
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 R
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
20 matches
Mail list logo
