You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Joe Witt <jo...@apache.org> on 2024/11/05 16:20:04 UTC
[discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
NiFi User Community:
TLDR: We would like to hear your thoughts on how we best communicate to the
user base about the importance of moving to NiFi 2.x.
The NiFi 1.x line has enjoyed more than 8 full years of strong support and
guarantees as it relates to Java 8 compatibility, flow compatibility from
release to release, and we've on average produced more than 4 releases per
year throughout that time.
For the past three years though the NiFi developer base has recognized the
1.x line has reached its natural conclusion phase as EOL was declared or
being declared soon for key components we rely on to maintain those NiFi
1.x guarantees for the users. These are critical components such as the
underlying JVM, key application framework dependencies like Spring, and
Jetty, our front-end codebase and many other smaller but important
libraries we rely on.
To address this we set about creating for and executing a plan towards a
better future for the NiFi project called NiFi 2.0. During the past year
we've created four different milestone releases of the Apache NiFi 2.x line
and many users are already there including production users as well as
vendor supported users outside the NiFi open source community who have
relied on NiFi 2.x for nearly a year.
Yesterday we're very pleased to have finally reached a point where the NIFi
2.0 line is now officially GA.
We encourage all users to migrate to it or make plans to migrate to it as
soon as practical. We realize for some users that it creates hardship and
we remain committed to minimizing such difficulties while also ensuring we
have a strong path forward to continue to evolve and grow the project and
user base.
There are many new components in the 2.x line and many old components no
longer present at all or by default on the 2.x line. The UI is completely
new but should be very familiar. You have to move to a base of Java 21.
Flows (the json form) by and large should migrate well or when they don't
we make the cases often quite manageable but it will require in some cases
user effort. We renamed some things which will create some complexity.
The net of it is moving from 1.x to 2.x is more work and harder than moving
from any previous 1.x release to a 1.x-next release.
Meanwhile, as I described, the NiFi 1.x line has reached a point where
addressing many classes of vulnerabile libraries is simply not possible.
The 2.x line by comparison was just released with our first ever entirely
clean vulnerability scan (compared to 100s of libs in the 1.x line).
We recognize some users will take a long time to migrate. The NiFi 1.x
line will remain available for a very very long time. However, we don't
want users to be misled in any way thinking we'll be available or able to
fix vulnerabilities or even analyze them reasonably on 1.x.
The ask to the user base then is what would be a helpful way of
communicating to the user base the importance of migrating and how to seek
help/ask questions? Where would you look for this information or expect it
to be? Would you expect us to call this 'End of Life' 'End of support'
etc..?
Thanks
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Russell Bateman <ru...@windofkeltia.com>.
I'm not very good at the marketing drivel, but here's a stab I took just
now. I'm sure others can improve upon it.
Imitation of the Downloads page was done to reduce explanations. Open it
with your browser (it stands alone and offers no links to anywhere).
On 11/5/24 09:34, Joe Witt wrote:
> Thanks Russ. Can you suggest/offer some specific text we should put
> there?
>
>
>
> On Tue, Nov 5, 2024 at 9:31 AM Russell Bateman <ru...@windofkeltia.com>
> wrote:
>
> There may be several places that would make good notification
> points for moving to 2.x. However, in my mind, the most important
> would be something polite, thorough, but not too scary, etc. at
> the Apache NiFi Downloads page--precisely where people go for
> installation artifacts.
>
>
> On 11/5/24 09:20, Joe Witt wrote:
>> NiFi User Community:
>>
>> TLDR: We would like to hear your thoughts on how we best
>> communicate to the user base about the importance of moving to
>> NiFi 2.x.
>>
>> The NiFi 1.x line has enjoyed more than 8 full years of strong
>> support and guarantees as it relates to Java 8 compatibility,
>> flow compatibility from release to release, and we've on average
>> produced more than 4 releases per year throughout that time.
>>
>> For the past three years though the NiFi developer base has
>> recognized the 1.x line has reached its natural conclusion phase
>> as EOL was declared or being declared soon for key components we
>> rely on to maintain those NiFi 1.x guarantees for the users.
>> These are critical components such as the underlying JVM, key
>> application framework dependencies like Spring, and Jetty, our
>> front-end codebase and many other smaller but important libraries
>> we rely on.
>>
>> To address this we set about creating for and executing a plan
>> towards a better future for the NiFi project called NiFi 2.0.
>> During the past year we've created four different milestone
>> releases of the Apache NiFi 2.x line and many users are already
>> there including production users as well as vendor supported
>> users outside the NiFi open source community who have relied on
>> NiFi 2.x for nearly a year.
>>
>> Yesterday we're very pleased to have finally reached a point
>> where the NIFi 2.0 line is now officially GA.
>>
>> We encourage all users to migrate to it or make plans to migrate
>> to it as soon as practical. We realize for some users that it
>> creates hardship and we remain committed to minimizing such
>> difficulties while also ensuring we have a strong path forward to
>> continue to evolve and grow the project and user base.
>>
>> There are many new components in the 2.x line and many old
>> components no longer present at all or by default on the 2.x
>> line. The UI is completely new but should be very familiar. You
>> have to move to a base of Java 21. Flows (the json form) by and
>> large should migrate well or when they don't we make the cases
>> often quite manageable but it will require in some cases user
>> effort. We renamed some things which will create some
>> complexity. The net of it is moving from 1.x to 2.x is more work
>> and harder than moving from any previous 1.x release to a
>> 1.x-next release.
>>
>> Meanwhile, as I described, the NiFi 1.x line has reached a point
>> where addressing many classes of vulnerabile libraries is simply
>> not possible. The 2.x line by comparison was just released with
>> our first ever entirely clean vulnerability scan (compared to
>> 100s of libs in the 1.x line).
>>
>> We recognize some users will take a long time to migrate. The
>> NiFi 1.x line will remain available for a very very long time.
>> However, we don't want users to be misled in any way thinking
>> we'll be available or able to fix vulnerabilities or even analyze
>> them reasonably on 1.x.
>>
>> The ask to the user base then is what would be a helpful way of
>> communicating to the user base the importance of migrating and
>> how to seek help/ask questions? Where would you look for this
>> information or expect it to be? Would you expect us to call this
>> 'End of Life' 'End of support' etc..?
>>
>>
>> Thanks
>
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Joe Witt <jo...@gmail.com>.
Thanks Russ. Can you suggest/offer some specific text we should put there?
On Tue, Nov 5, 2024 at 9:31 AM Russell Bateman <ru...@windofkeltia.com>
wrote:
> There may be several places that would make good notification points for
> moving to 2.x. However, in my mind, the most important would be something
> polite, thorough, but not too scary, etc. at the Apache NiFi Downloads
> page--precisely where people go for installation artifacts.
>
>
> On 11/5/24 09:20, Joe Witt wrote:
>
> NiFi User Community:
>
> TLDR: We would like to hear your thoughts on how we best communicate to
> the user base about the importance of moving to NiFi 2.x.
>
> The NiFi 1.x line has enjoyed more than 8 full years of strong support and
> guarantees as it relates to Java 8 compatibility, flow compatibility from
> release to release, and we've on average produced more than 4 releases per
> year throughout that time.
>
> For the past three years though the NiFi developer base has recognized the
> 1.x line has reached its natural conclusion phase as EOL was declared or
> being declared soon for key components we rely on to maintain those NiFi
> 1.x guarantees for the users. These are critical components such as the
> underlying JVM, key application framework dependencies like Spring, and
> Jetty, our front-end codebase and many other smaller but important
> libraries we rely on.
>
> To address this we set about creating for and executing a plan towards a
> better future for the NiFi project called NiFi 2.0. During the past year
> we've created four different milestone releases of the Apache NiFi 2.x line
> and many users are already there including production users as well as
> vendor supported users outside the NiFi open source community who have
> relied on NiFi 2.x for nearly a year.
>
> Yesterday we're very pleased to have finally reached a point where the
> NIFi 2.0 line is now officially GA.
>
> We encourage all users to migrate to it or make plans to migrate to it as
> soon as practical. We realize for some users that it creates hardship and
> we remain committed to minimizing such difficulties while also ensuring we
> have a strong path forward to continue to evolve and grow the project and
> user base.
>
> There are many new components in the 2.x line and many old components no
> longer present at all or by default on the 2.x line. The UI is completely
> new but should be very familiar. You have to move to a base of Java 21.
> Flows (the json form) by and large should migrate well or when they don't
> we make the cases often quite manageable but it will require in some cases
> user effort. We renamed some things which will create some complexity.
> The net of it is moving from 1.x to 2.x is more work and harder than moving
> from any previous 1.x release to a 1.x-next release.
>
> Meanwhile, as I described, the NiFi 1.x line has reached a point where
> addressing many classes of vulnerabile libraries is simply not possible.
> The 2.x line by comparison was just released with our first ever entirely
> clean vulnerability scan (compared to 100s of libs in the 1.x line).
>
> We recognize some users will take a long time to migrate. The NiFi 1.x
> line will remain available for a very very long time. However, we don't
> want users to be misled in any way thinking we'll be available or able to
> fix vulnerabilities or even analyze them reasonably on 1.x.
>
> The ask to the user base then is what would be a helpful way of
> communicating to the user base the importance of migrating and how to seek
> help/ask questions? Where would you look for this information or expect it
> to be? Would you expect us to call this 'End of Life' 'End of support'
> etc..?
>
>
> Thanks
>
>
>
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Russell Bateman <ru...@windofkeltia.com>.
There may be several places that would make good notification points for
moving to 2.x. However, in my mind, the most important would be
something polite, thorough, but not too scary, etc. at the Apache NiFi
Downloads page--precisely where people go for installation artifacts.
On 11/5/24 09:20, Joe Witt wrote:
> NiFi User Community:
>
> TLDR: We would like to hear your thoughts on how we best communicate
> to the user base about the importance of moving to NiFi 2.x.
>
> The NiFi 1.x line has enjoyed more than 8 full years of strong support
> and guarantees as it relates to Java 8 compatibility, flow
> compatibility from release to release, and we've on average produced
> more than 4 releases per year throughout that time.
>
> For the past three years though the NiFi developer base has recognized
> the 1.x line has reached its natural conclusion phase as EOL was
> declared or being declared soon for key components we rely on to
> maintain those NiFi 1.x guarantees for the users. These are critical
> components such as the underlying JVM, key application framework
> dependencies like Spring, and Jetty, our front-end codebase and many
> other smaller but important libraries we rely on.
>
> To address this we set about creating for and executing a plan towards
> a better future for the NiFi project called NiFi 2.0. During the past
> year we've created four different milestone releases of the Apache
> NiFi 2.x line and many users are already there including production
> users as well as vendor supported users outside the NiFi open source
> community who have relied on NiFi 2.x for nearly a year.
>
> Yesterday we're very pleased to have finally reached a point where the
> NIFi 2.0 line is now officially GA.
>
> We encourage all users to migrate to it or make plans to migrate to it
> as soon as practical. We realize for some users that it creates
> hardship and we remain committed to minimizing such difficulties while
> also ensuring we have a strong path forward to continue to evolve and
> grow the project and user base.
>
> There are many new components in the 2.x line and many old components
> no longer present at all or by default on the 2.x line. The UI is
> completely new but should be very familiar. You have to move to a base
> of Java 21. Flows (the json form) by and large should migrate well or
> when they don't we make the cases often quite manageable but it will
> require in some cases user effort. We renamed some things which will
> create some complexity. The net of it is moving from 1.x to 2.x is
> more work and harder than moving from any previous 1.x release to a
> 1.x-next release.
>
> Meanwhile, as I described, the NiFi 1.x line has reached a point where
> addressing many classes of vulnerabile libraries is simply not
> possible. The 2.x line by comparison was just released with our first
> ever entirely clean vulnerability scan (compared to 100s of libs in
> the 1.x line).
>
> We recognize some users will take a long time to migrate. The NiFi 1.x
> line will remain available for a very very long time. However, we
> don't want users to be misled in any way thinking we'll be available
> or able to fix vulnerabilities or even analyze them reasonably on 1.x.
>
> The ask to the user base then is what would be a helpful way of
> communicating to the user base the importance of migrating and how to
> seek help/ask questions? Where would you look for this information or
> expect it to be? Would you expect us to call this 'End of Life' 'End
> of support' etc..?
>
>
> Thanks
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Joe Obernberger <jo...@gmail.com>.
I have a NiFi 2.0.0 cluster (3 nodes) running in kubernetes now using
NiFiKop (https://github.com/konpyutaika/nifikop) to deploy. So far it is
working very nicely, and I love the new dark mode in the UI! :)
Here is the configuration yaml that I used in case it helps anyone -
comments appreciated:
apiVersion: nifi.konpyutaika.com/v1
kind: NifiCluster
metadata:
name: testcluster
spec:
service:
headlessEnabled: true
annotations:
tyty: ytyt
labels:
cluster-name: testcluster
tete: titi
externalServices:
- metadata:
annotations:
toto: tata
labels:
cluster-name: driver-testcluster
titi: tutu
name: driver-ip
spec:
portConfigs:
- internalListenerName: http
port: 8080
type: LoadBalancer
clusterImage: "apache/nifi:2.0.0"
initContainerImage: "bash:5.2.2"
oneNifiNodePerNode: true
readOnlyConfig:
nifiProperties:
overrideConfigs: |
nifi.sensitive.props.key=changeMechangeMe
nifi.sensitive.props.algorithm=NIFI_PBKDF2_AES_GCM_256
nifi.flowfile.repository.checkpoint.interval=2 mins
nifi.flowfile.repository.always.sync=false
nifi.swap.manager.implementation=org.apache.nifi.controller.FileSystemSwapManager
nifi.queue.swap.threshold=200000
nifi.content.repository.implementation=org.apache.nifi.controller.repository.FileSystemRepository
nifi.content.claim.max.appendable.size=10 MB
nifi.content.repository.directory.default=../content_repository
nifi.content.repository.archive.max.retention.period=1 days
nifi.content.repository.archive.max.usage.percentage=50%
nifi.content.repository.archive.backpressure.percentage=60%
nifi.content.repository.archive.enabled=false
nifi.content.repository.always.sync=false
nifi.content.viewer.url=/nifi-content-viewer/
nifi.content.repository.archive.cleanup.frequency=300 sec
nifi.provenance.repository.directory.default=../provenance_repository
nifi.provenance.repository.max.storage.time=5 days
nifi.provenance.repository.rollover.time=300 secs
nifi.provenance.repository.rollover.size=256 MB
nifi.provenance.repository.query.threads=2
nifi.provenance.repository.index.threads=3
nifi.provenance.repository.compress.on.rollover=false
nifi.provenance.repository.always.sync=false
nifi.provenance.repository.journal.count=16
nifi.provenance.repository.index.shard.size=1024 MB
nifi.provenance.repository.max.attribute.length=128
nifi.ui.banner.text=Fireside_NiFi
nifi.nar.library.autoload.directory=/opt/nifi/nifi-current/nar_extensions
bootstrapProperties:
nifiJvmMemory: "38g"
pod:
annotations:
toto: tata
labels:
cluster-name: testcluster
titi: tutu
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 600
timeoutSeconds: 60
periodSeconds: 120
successThreshold: 1
failureThreshold: 5
readinessProbe:
exec:
command:
- bash
- '-c'
- curl -kv http://$(hostname -f):8080/nifi-api
initialDelaySeconds: 600
timeoutSeconds: 60
periodSeconds: 120
successThreshold: 1
failureThreshold: 5
nodeConfigGroups:
default_group:
imagePullPolicy: IfNotPresent
isNode: true
serviceAccountName: default
provenanceStorage: "8000 GB"
externalVolumeConfigs:
- name: shared-storage
nfs:
server: hdfs.querymasters.com
path: /ifs/data/nifi
readOnly: false
mountPath: /mnt
storageConfigs:
- mountPath: "/opt/nifi/data"
name: data
reclaimPolicy: Delete
pvcSpec:
accessModes:
- ReadWriteOnce
storageClassName: "netapp-ssd"
resources:
requests:
storage: 10Gi
- mountPath: "/opt/nifi/content_repository"
name: content
reclaimPolicy: Delete
pvcSpec:
accessModes:
- ReadWriteOnce
storageClassName: "netapp-ssd"
resources:
requests:
storage: 100Gi
- mountPath: "/opt/nifi/flowfile_repository"
name: flowfile
reclaimPolicy: Delete
pvcSpec:
accessModes:
- ReadWriteOnce
storageClassName: "netapp-ssd"
resources:
requests:
storage: 10Gi
- mountPath: "/opt/nifi/provenance_repository"
name: provenance
reclaimPolicy: Delete
pvcSpec:
accessModes:
- ReadWriteOnce
storageClassName: "netapp-ssd"
resources:
requests:
storage: 8192Gi
- mountPath: "/opt/nifi/nifi-current/nar_extensions"
name: extensions
reclaimPolicy: Delete
pvcSpec:
accessModes:
- ReadWriteOnce
storageClassName: "netapp-hdd"
resources:
requests:
storage: 1Gi
resourcesRequirements:
limits:
cpu: "12"
memory: 52Gi
requests:
cpu: "3"
memory: 49Gi
nodes:
- id: 1
nodeConfigGroup: "default_group"
- id: 2
nodeConfigGroup: "default_group"
- id: 3
nodeConfigGroup: "default_group"
propagateLabels: true
nifiClusterTaskSpec:
retryDurationMinutes: 10
listenersConfig:
internalListeners:
- containerPort: 8080
type: http
name: http
- containerPort: 6007
type: cluster
name: cluster
- containerPort: 10000
type: s2s
name: s2s
- containerPort: 9090
type: prometheus
name: prometheus
- containerPort: 6342
type: load-balance
name: load-balance
-Joe
On 11/6/2024 2:51 AM, Dirk Olmes wrote:
> On 11/5/24 22:24, Joe Obernberger wrote:
>> Looking forward to working with 2.0! Are there instructions / helm
>> chart / a nice way to deploy a nifi cluster to kubernetes? We're
>> using 1.25 with the cetic helm chart
>> (https://github.com/cetic/helm-nifi), which also deploys zookeeper.
>> It's my understanding that is no longer necessary as NiFi will now
>> use Kubernetes for the same purpose.
>
> Joe, you're touching an interesting topic here. We have just
> introduced Nifi at work using the cetic helm chart but had to learn
> along the way that it is no longer maintained. We had to fork it to
> add some settings required for our LDAP authentication so I already
> got my feet wet with it a bit.
>
> However, building a new helm chart for Nifi 2.0 looks like quite an
> endeavour, too much for me alone. I've seen others mention
> helm/kubernetes deployments here before so maybe there's interest in
> working together on a Nifi 2.x helm chart?
>
> -dirk
>
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Jim Halfpenny via users <us...@nifi.apache.org>.
Hi,
It's worth nothing that Stackable has an operator for Apache NiFi and we
have experimental support for 2.0.0-M4 right now. We’ll add support for the
released version of 2.0.0 in our next release later this month. This is an
alternative to building a new Helm chart, though I appreciate Helm
installations differ from operator managed ones and there is room for both.
Stackable Operator for Apache NiFi :: nifi :: Stackable Documentation
<https://docs.stackable.tech/home/stable/nifi/>
docs.stackable.tech <https://docs.stackable.tech/home/stable/nifi/>
[image: favicon.png] <https://docs.stackable.tech/home/stable/nifi/>
<https://docs.stackable.tech/home/stable/nifi/>
Kind regards,
Jim
On 7 Nov 2024, at 22:03, Joe Obernberger <jo...@gmail.com>
wrote:
Hi Dirk - sorry for the delay. Yes, we have a couple people who are
interested in helping out here. There is an open source project called
NiFiKop (https://konpyutaika.github.io/nifikop/), that installs an
operator, but also still looks more tied to 1.x of NiFi as their quickstart
still refers to setting up zookeeper.
I'd love to have a values.yaml that sets up various key parameters for
NiFi, ram, storage for content/repo/provenance, etc.. and do a cluster
install via help.
-Joe
On 11/6/2024 2:51 AM, Dirk Olmes wrote:
On 11/5/24 22:24, Joe Obernberger wrote:
Looking forward to working with 2.0! Are there instructions / helm chart /
a nice way to deploy a nifi cluster to kubernetes? We're using 1.25 with
the cetic helm chart (https://github.com/cetic/helm-nifi), which also
deploys zookeeper. It's my understanding that is no longer necessary as
NiFi will now use Kubernetes for the same purpose.
Joe, you're touching an interesting topic here. We have just introduced
Nifi at work using the cetic helm chart but had to learn along the way that
it is no longer maintained. We had to fork it to add some settings required
for our LDAP authentication so I already got my feet wet with it a bit.
However, building a new helm chart for Nifi 2.0 looks like quite an
endeavour, too much for me alone. I've seen others mention helm/kubernetes
deployments here before so maybe there's interest in working together on a
Nifi 2.x helm chart?
-dirk
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Joe Obernberger <jo...@gmail.com>.
Hi Dirk - sorry for the delay. Yes, we have a couple people who are
interested in helping out here. There is an open source project called
NiFiKop (https://konpyutaika.github.io/nifikop/), that installs an
operator, but also still looks more tied to 1.x of NiFi as their
quickstart still refers to setting up zookeeper.
I'd love to have a values.yaml that sets up various key parameters for
NiFi, ram, storage for content/repo/provenance, etc.. and do a cluster
install via help.
-Joe
On 11/6/2024 2:51 AM, Dirk Olmes wrote:
> On 11/5/24 22:24, Joe Obernberger wrote:
>> Looking forward to working with 2.0! Are there instructions / helm
>> chart / a nice way to deploy a nifi cluster to kubernetes? We're
>> using 1.25 with the cetic helm chart
>> (https://github.com/cetic/helm-nifi), which also deploys zookeeper.
>> It's my understanding that is no longer necessary as NiFi will now
>> use Kubernetes for the same purpose.
>
> Joe, you're touching an interesting topic here. We have just
> introduced Nifi at work using the cetic helm chart but had to learn
> along the way that it is no longer maintained. We had to fork it to
> add some settings required for our LDAP authentication so I already
> got my feet wet with it a bit.
>
> However, building a new helm chart for Nifi 2.0 looks like quite an
> endeavour, too much for me alone. I've seen others mention
> helm/kubernetes deployments here before so maybe there's interest in
> working together on a Nifi 2.x helm chart?
>
> -dirk
>
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Dirk Olmes <di...@codedo.de>.
On 11/5/24 22:24, Joe Obernberger wrote:
> Looking forward to working with 2.0! Are there instructions / helm
> chart / a nice way to deploy a nifi cluster to kubernetes? We're using
> 1.25 with the cetic helm chart (https://github.com/cetic/helm-nifi),
> which also deploys zookeeper. It's my understanding that is no longer
> necessary as NiFi will now use Kubernetes for the same purpose.
Joe, you're touching an interesting topic here. We have just introduced
Nifi at work using the cetic helm chart but had to learn along the way
that it is no longer maintained. We had to fork it to add some settings
required for our LDAP authentication so I already got my feet wet with
it a bit.
However, building a new helm chart for Nifi 2.0 looks like quite an
endeavour, too much for me alone. I've seen others mention
helm/kubernetes deployments here before so maybe there's interest in
working together on a Nifi 2.x helm chart?
-dirk
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Joe Obernberger <jo...@gmail.com>.
Looking forward to working with 2.0! Are there instructions / helm
chart / a nice way to deploy a nifi cluster to kubernetes? We're using
1.25 with the cetic helm chart (https://github.com/cetic/helm-nifi),
which also deploys zookeeper. It's my understanding that is no longer
necessary as NiFi will now use Kubernetes for the same purpose.
Thank you!
-Joe
On 11/5/2024 11:20 AM, Joe Witt wrote:
> NiFi User Community:
>
> TLDR: We would like to hear your thoughts on how we best communicate
> to the user base about the importance of moving to NiFi 2.x.
>
> The NiFi 1.x line has enjoyed more than 8 full years of strong support
> and guarantees as it relates to Java 8 compatibility, flow
> compatibility from release to release, and we've on average produced
> more than 4 releases per year throughout that time.
>
> For the past three years though the NiFi developer base has recognized
> the 1.x line has reached its natural conclusion phase as EOL was
> declared or being declared soon for key components we rely on to
> maintain those NiFi 1.x guarantees for the users. These are critical
> components such as the underlying JVM, key application framework
> dependencies like Spring, and Jetty, our front-end codebase and many
> other smaller but important libraries we rely on.
>
> To address this we set about creating for and executing a plan towards
> a better future for the NiFi project called NiFi 2.0. During the past
> year we've created four different milestone releases of the Apache
> NiFi 2.x line and many users are already there including production
> users as well as vendor supported users outside the NiFi open source
> community who have relied on NiFi 2.x for nearly a year.
>
> Yesterday we're very pleased to have finally reached a point where the
> NIFi 2.0 line is now officially GA.
>
> We encourage all users to migrate to it or make plans to migrate to it
> as soon as practical. We realize for some users that it creates
> hardship and we remain committed to minimizing such difficulties while
> also ensuring we have a strong path forward to continue to evolve and
> grow the project and user base.
>
> There are many new components in the 2.x line and many old components
> no longer present at all or by default on the 2.x line. The UI is
> completely new but should be very familiar. You have to move to a base
> of Java 21. Flows (the json form) by and large should migrate well or
> when they don't we make the cases often quite manageable but it will
> require in some cases user effort. We renamed some things which will
> create some complexity. The net of it is moving from 1.x to 2.x is
> more work and harder than moving from any previous 1.x release to a
> 1.x-next release.
>
> Meanwhile, as I described, the NiFi 1.x line has reached a point where
> addressing many classes of vulnerabile libraries is simply not
> possible. The 2.x line by comparison was just released with our first
> ever entirely clean vulnerability scan (compared to 100s of libs in
> the 1.x line).
>
> We recognize some users will take a long time to migrate. The NiFi 1.x
> line will remain available for a very very long time. However, we
> don't want users to be misled in any way thinking we'll be available
> or able to fix vulnerabilities or even analyze them reasonably on 1.x.
>
> The ask to the user base then is what would be a helpful way of
> communicating to the user base the importance of migrating and how to
> seek help/ask questions? Where would you look for this information or
> expect it to be? Would you expect us to call this 'End of Life' 'End
> of support' etc..?
>
>
> Thanks
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Re: [discuss] NiFi 2.0 is here - what this means for the 1.x line and input from the user base
Posted by Rafael Fracasso <ra...@gmail.com>.
Hi Joe,
The first question my organization asked when I mentioned 2.0 was: What are
the pros and cons?
I think it would be nice to have a more technical list of what impacts 2.0
has on your server in a positive way.
How much better does NiFi 2.0 use JVM 21 compared to 1.x on 11?
And also the cons, such as having to rewrite jython scripts in groovy or
create a python processor, for example.
Thanks!
On Tue, Nov 5, 2024 at 12:20 PM Joe Witt <jo...@apache.org> wrote:
> NiFi User Community:
>
> TLDR: We would like to hear your thoughts on how we best communicate to
> the user base about the importance of moving to NiFi 2.x.
>
> The NiFi 1.x line has enjoyed more than 8 full years of strong support and
> guarantees as it relates to Java 8 compatibility, flow compatibility from
> release to release, and we've on average produced more than 4 releases per
> year throughout that time.
>
> For the past three years though the NiFi developer base has recognized the
> 1.x line has reached its natural conclusion phase as EOL was declared or
> being declared soon for key components we rely on to maintain those NiFi
> 1.x guarantees for the users. These are critical components such as the
> underlying JVM, key application framework dependencies like Spring, and
> Jetty, our front-end codebase and many other smaller but important
> libraries we rely on.
>
> To address this we set about creating for and executing a plan towards a
> better future for the NiFi project called NiFi 2.0. During the past year
> we've created four different milestone releases of the Apache NiFi 2.x line
> and many users are already there including production users as well as
> vendor supported users outside the NiFi open source community who have
> relied on NiFi 2.x for nearly a year.
>
> Yesterday we're very pleased to have finally reached a point where the
> NIFi 2.0 line is now officially GA.
>
> We encourage all users to migrate to it or make plans to migrate to it as
> soon as practical. We realize for some users that it creates hardship and
> we remain committed to minimizing such difficulties while also ensuring we
> have a strong path forward to continue to evolve and grow the project and
> user base.
>
> There are many new components in the 2.x line and many old components no
> longer present at all or by default on the 2.x line. The UI is completely
> new but should be very familiar. You have to move to a base of Java 21.
> Flows (the json form) by and large should migrate well or when they don't
> we make the cases often quite manageable but it will require in some cases
> user effort. We renamed some things which will create some complexity.
> The net of it is moving from 1.x to 2.x is more work and harder than moving
> from any previous 1.x release to a 1.x-next release.
>
> Meanwhile, as I described, the NiFi 1.x line has reached a point where
> addressing many classes of vulnerabile libraries is simply not possible.
> The 2.x line by comparison was just released with our first ever entirely
> clean vulnerability scan (compared to 100s of libs in the 1.x line).
>
> We recognize some users will take a long time to migrate. The NiFi 1.x
> line will remain available for a very very long time. However, we don't
> want users to be misled in any way thinking we'll be available or able to
> fix vulnerabilities or even analyze them reasonably on 1.x.
>
> The ask to the user base then is what would be a helpful way of
> communicating to the user base the importance of migrating and how to seek
> help/ask questions? Where would you look for this information or expect it
> to be? Would you expect us to call this 'End of Life' 'End of support'
> etc..?
>
>
> Thanks
>