Ok.
I've just done.
https://issues.apache.org/jira/browse/NIFI-8944
Best Regards.
Eduardo Fontes
On Fri, Jul 23, 2021 at 2:23 PM Pierre Villard
wrote:
> Thanks Eduardo, the image still didn't go through.
> Do you mind filing a JIRA and attaching the image there? This is definitely
>
Hi Pierre,
I'll try to send image as a attachment (error.png)
The nifi.properties, related props:
# Component and Node Status History Repository
nifi.components.status.repository.implementation=org.apache.nifi.controller.status.history.EmbeddedQuestDbStatusHistoryRepository
# Volatile Status
Only a thought:
I think this is something about filtering data. It seems it's bringing
everything at once.
Thanks.
Eduardo Fontes
On Fri, Jul 23, 2021 at 2:23 PM Pierre Villard
wrote:
> Thanks Eduardo, the image still didn't go through.
> Do you mind filing a JIRA and attaching the image
Team,
I created the following page on the Apache NiFi wiki to track proposed
goals and particular focus areas. If the page should go under another
section of the wiki, it can be moved.
https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
The Primary Goals section is
Thanks Eduardo, the image still didn't go through.
Do you mind filing a JIRA and attaching the image there? This is definitely
something we want to figure out!
Thanks,
Pierre
Le ven. 23 juil. 2021 à 18:56, Eduardo Fontes a
écrit :
> Hi Pierre,
>
> I'll try to send image as a attachment
Bringing up Elastic also reminds me that the Elastic framework has just
recently transitioned out of Open Source, so to acknowledge that, maybe
some effort toward OpenSearch--I say this not understanding exactly how
this sort of thing is considered in a large-scale, world-class software
Joe,
I apologize for the off-topic intrusion, but what replaces templates?
The Registry? Templates rocked and we have used them since 0.5.x.
Russ
On 7/23/21 8:31 AM, Joe Witt wrote:
David,
I think this is a highly reasonable approach and such a focus will
greatly help make a 2.0 release
I'd say we'll have to address the branching strategy but not yet.
Let's get a sense of the scope/specific bits we want to tackle in 2.0
then worry about best way to go about it.
On Fri, Jul 23, 2021 at 9:39 AM David Handermann
wrote:
>
> Thanks to everyone who has provided feedback thus far, it
I would be extremely careful about moving to Java 11 -- especially if NiFi
1.x is not actively maintained. I am sure it's not news to anyone, but a
lot (most?) of people are still on Java 8, for better or worse, and I do
not think moving without a strong, compelling reason is advisable. It's not
Jon
You're right we have to be careful and you're right there are still
significant Java 8 users out there. But we also have to be careful
about security and sustainability of the codebase. If we had talked
about this last year when that article came out I'd have agreed it is
too early.
I'm a +1 for removing pretty much all of this stuff. There are security
implications to keeping old dependencies around, so the more old code we
can remove the better. I agree that eventually we need to move to
supporting only Java 11+, and as our next release will probably be about 4
- 6 months
I'm a +1 for this... Not sure if this falls under "Removing Deprecated
Components", but I think we should also look at anything that has been
marked as deprecated throughout the code base as a candidate for
removal. There are quite a few classes, methods, properties, etc that
have been waiting for
Hi all,
I have a 3 node NiFi 1.14 Cluster, Java 11, CentOS 7
I've started it yesterday, and today when I clicked on "Node Status
History" I received an error:
[image: image.png]
This is a 100MB error page !
Am I doing something wrong?
Here is the nifi-app.log error stack trace.
Thanks to everyone who has provided feedback thus far, it is good to see
general interest in moving forward with a release focusing on technical
debt removal.
It seems like it would be helpful to start gathering removal candidates on
a Confluence wiki page, and then turning those into Jira
Along with the itemized list for ancient components we should look at
updating versions of drivers, SDKs, etc. for external systems such as
Elasticsearch, Cassandra, etc. There may be breaking changes but 2.0
is probably the right time to get things up to date to make them more
useful to more
Team,
With all of the excellent work that many have contributed to NiFi over the
years, the code base has also accumulated some amount of technical debt. A
handful of components have been marked as deprecated, and some components
remain in the code base to support integration with old versions of
David,
I think this is a highly reasonable approach and such a focus will
greatly help make a 2.0 release far more approachable to knock out.
Not only that but tech debt reduction would help make work towards
major features we'd think about in a 'major release' sense more
approachable.
We should
Hi Eduardo,
The image didn't go through. Also can you share your nifi.properties
configuration related to status history configuration.
Thanks,
Pierre
Le ven. 23 juil. 2021 à 17:00, Eduardo Fontes a
écrit :
> Hi all,
>
> I have a 3 node NiFi 1.14 Cluster, Java 11, CentOS 7
>
> I've started it
I quite like this idea. It seemed like the first 2.0 release had been being
held out for some bigger innovations (nar registry?), but that has also pushed
out making nice breaking changes.
What would be the mechanics here? Just starting feeding all the candidates into
JIRA? Listing out
Hi,
I found a project Plumber, try this.
https://github.com/TouK/plumber
Tony Koval
On 2021/07/22 03:25:31, Phil H mailto:g...@gmail.com>> wrote:
> Hi there,>
>
> I use the built in unit tests in the maven processor archetype for each of>
> my processors, but I would like to set up
Russ
Yeah the flow registry is a key part of it. But also now you can
download the flow definition in JSON (upload i think is there now
too). Templates offered a series of challenges such as we store them
in the flow definition which has made flows massive in an unintended
way which isn't fun
21 matches
Mail list logo
