Re: [DISCUSS] NiFi and Java 11

[Sivaprasanna]

Yep. Adding to GitHub template is a great idea.

On Thu, 4 Apr 2019 at 5:27 AM, Andy LoPresto  wrote:

> We should add that to the Developer Guide [1], Contributor Guide [2], note
> it in the Migration Guide [3] when it takes effect, and include it in the
> GitHub PR template as well.
>
> [1] https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html <
> https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html>
> [2] https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide <
> https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide>
> [3] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance <
> https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance>
>
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Apr 3, 2019, at 1:16 PM, Sivaprasanna 
> wrote:
> >
> > Sounds good to me.
> >
> > So contributors who bring in new changes are expected to write the code
> > that should be compatible with both Java 8 as well as Java 11, right?
> >
> > Do we see anything that we should have in our site that would help the
> > contributors/users with this change? Something like a document that
> > explains best practices which a developer should follow so that the
> change
> > which the developer is bringing in should run fine in both 8 and 11.
> >
> > -
> > Sivaprasanna
> >
> > On Thu, 4 Apr 2019 at 12:18 AM, Pierre Villard <
> pierre.villard...@gmail.com>
> > wrote:
> >
> >> Sounds good to me as well. Given the latest news on Java 8, having the 2
> >> PRs merged in would be great!
> >>
> >> Thanks,
> >> Pierre
> >>
> >> Le mer. 3 avr. 2019 à 20:34, Joe Witt  a écrit :
> >>
> >>> Jeff
> >>>
> >>> This seems very reasonable and thorough to me.
> >>>
> >>> The only short term implication that we'd have to buy into then is that
> >> PRs
> >>> going forward need to be able to build on both Java 8 and 11 which
> seems
> >> a
> >>> very fair way to bridge toward moving to Java 11 as the base
> requirement
> >> in
> >>> the next major release of NiFi (2.x).
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>> On Wed, Apr 3, 2019 at 2:19 PM Jeff  wrote:
> >>>
>  I'm reaching out to the community today to propose a plan for moving
>  forward with NiFi on Java 11.
> 
>  There are currently two PRs that deal with Java 11 compatibility.  The
>  first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The
> >>> second
>  PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There
> >> are
> >>> a
>  lot of changes in the second PR, and it will require a lot of testing
> >> due
>  to the breadth of changes from dependency upgrades.  Please take a
> look
> >>> at
>  both of these PRs.  The earlier we can get feedback, the sooner we can
> >>> get
>  Java 11 compatibility in an Apache NiFi release.
> 
>  I would to discuss with the community the following plan for upcoming
> >>> NiFi
>  releases as they pertain to Java 11:
> 
>  For the 1.x release line, from either 1.10 or 1.11 (depending on when
> >>> these
>  two PRs are merged to master) and onward, NiFi will be compatible with
> >>> both
>  Java 8 and 11 for building and running NiFi:
> 
>    - Build on Java 8, run on Java 8
>    - Build on Java 8, run on Java 11
>    - Build on Java 11, run on Java 11
> 
>  The 1.x release line will contain convenience builds for Java 8, and
> >> will
>  NOT contain convenience builds created from Java 11.  Users that want
> >> to
>  run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build
> >> from
>  the released source code.
> 
>  Once the Java 11 compatibility features [1] [2] are merged to master,
> >> PR
>  reviews will require building and testing with Java 8 and Java 11
> >> before
>  the PR is merged to master. We will add a new build to our Travis CI
>  instance to cover building on Java 11, which should help with the PR
>  process, since build status from Appveyor and Travis are shown on the
> >> PR.
>  This will allow an easier transition to the NiFi 2.x release line.
> 
>  For the 2.x release line, the minimum Java version would be Java 11,
> at
>  which point developers would be able to start using Java 11 language
>  features.  Java 12 is not designated to be an LTS release, with its
> >>> support
>  ending in September 2019.  I would not recommend making our minimum
> >> Java
>  version a non-LTS Java release unless we are prepared to do NiFi
> >> releases
>  to update the minimum Java version before the support for that version
> >> of
>  Java ends.
> 
>  Taking this approach means we can reasonably allow users to run on
> Java
> >>> 11
>  in the 1.x release line, ensure that we do not add commits which are
> >> not
>  Java 11 compatible, and make it easier to transition into the 2.x 

Re: [DISCUSS] NiFi and Java 11

[Andy LoPresto]

We should add that to the Developer Guide [1], Contributor Guide [2], note it 
in the Migration Guide [3] when it takes effect, and include it in the GitHub 
PR template as well. 

[1] https://nifi.apache.org/docs/nifi-docs/html/developer-guide.html 

[2] https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide 

[3] https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance 



Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Apr 3, 2019, at 1:16 PM, Sivaprasanna  wrote:
> 
> Sounds good to me.
> 
> So contributors who bring in new changes are expected to write the code
> that should be compatible with both Java 8 as well as Java 11, right?
> 
> Do we see anything that we should have in our site that would help the
> contributors/users with this change? Something like a document that
> explains best practices which a developer should follow so that the change
> which the developer is bringing in should run fine in both 8 and 11.
> 
> -
> Sivaprasanna
> 
> On Thu, 4 Apr 2019 at 12:18 AM, Pierre Villard 
> wrote:
> 
>> Sounds good to me as well. Given the latest news on Java 8, having the 2
>> PRs merged in would be great!
>> 
>> Thanks,
>> Pierre
>> 
>> Le mer. 3 avr. 2019 à 20:34, Joe Witt  a écrit :
>> 
>>> Jeff
>>> 
>>> This seems very reasonable and thorough to me.
>>> 
>>> The only short term implication that we'd have to buy into then is that
>> PRs
>>> going forward need to be able to build on both Java 8 and 11 which seems
>> a
>>> very fair way to bridge toward moving to Java 11 as the base requirement
>> in
>>> the next major release of NiFi (2.x).
>>> 
>>> Thanks
>>> Joe
>>> 
>>> On Wed, Apr 3, 2019 at 2:19 PM Jeff  wrote:
>>> 
 I'm reaching out to the community today to propose a plan for moving
 forward with NiFi on Java 11.
 
 There are currently two PRs that deal with Java 11 compatibility.  The
 first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The
>>> second
 PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There
>> are
>>> a
 lot of changes in the second PR, and it will require a lot of testing
>> due
 to the breadth of changes from dependency upgrades.  Please take a look
>>> at
 both of these PRs.  The earlier we can get feedback, the sooner we can
>>> get
 Java 11 compatibility in an Apache NiFi release.
 
 I would to discuss with the community the following plan for upcoming
>>> NiFi
 releases as they pertain to Java 11:
 
 For the 1.x release line, from either 1.10 or 1.11 (depending on when
>>> these
 two PRs are merged to master) and onward, NiFi will be compatible with
>>> both
 Java 8 and 11 for building and running NiFi:
 
   - Build on Java 8, run on Java 8
   - Build on Java 8, run on Java 11
   - Build on Java 11, run on Java 11
 
 The 1.x release line will contain convenience builds for Java 8, and
>> will
 NOT contain convenience builds created from Java 11.  Users that want
>> to
 run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build
>> from
 the released source code.
 
 Once the Java 11 compatibility features [1] [2] are merged to master,
>> PR
 reviews will require building and testing with Java 8 and Java 11
>> before
 the PR is merged to master. We will add a new build to our Travis CI
 instance to cover building on Java 11, which should help with the PR
 process, since build status from Appveyor and Travis are shown on the
>> PR.
 This will allow an easier transition to the NiFi 2.x release line.
 
 For the 2.x release line, the minimum Java version would be Java 11, at
 which point developers would be able to start using Java 11 language
 features.  Java 12 is not designated to be an LTS release, with its
>>> support
 ending in September 2019.  I would not recommend making our minimum
>> Java
 version a non-LTS Java release unless we are prepared to do NiFi
>> releases
 to update the minimum Java version before the support for that version
>> of
 Java ends.
 
 Taking this approach means we can reasonably allow users to run on Java
>>> 11
 in the 1.x release line, ensure that we do not add commits which are
>> not
 Java 11 compatible, and make it easier to transition into the 2.x line
>>> for
 NiFi.
 
 - Jeff
 
 [1] https://github.com/apache/nifi/pull/3174
 [2] https://github.com/apache/nifi/pull/3404
 
>>> 
>> 

Re: initial component access policies

[Bryan Bende]

I remember trying to solve this a long time ago during the 1.0.0
development when the new authorizer API was implemented, but I
honestly can't remember all the issues. A lot of stuff has changed
since so maybe a fresh look is worth it.

StandardFlowService already has a member variable with the Authorizer,
you can see examples of where it uses it. If its a ManagedAuthorizer
then you can get access to the policy provider and see if its a
configurable one.

The only issue I see with this approach is that its putting the
decision to seed the policies into the framework, where as for the
other policies it is a decision of the policy provider so it is done
inside the file-based provider. Not sure if this is really an issue,
but we just need to consider all the scenarios.

On Wed, Apr 3, 2019 at 4:44 PM Mark Bean  wrote:
>
> Bryan,
>
> Ok, thanks. Now, the issue is when there is no flow established yet. In
> that case, FileAccessPolicyProvider.populateInitialAdmin will not find the
> rootGroupId; it doesn't exist yet in cases where there is no flow.xml.gz on
> startup. So, component access policies cannot be created.
>
> The flow.xml.gz is initially created in StandardFlowService.load(DataFlow).
> Here, the rootGroupId is known (or can be derived from the controller.)
> However, at this point, there is no access to the FileAccessPolicyProvider
> which is required to updated the policies. Hence, the problem of not
> completing the authorizations (i.e. component policies) for an Initial
> Admin User.
>
> Do you have suggestions on how to access the FileAccessPolicyProvider (or
> more generally a ConfigurableAccessPolicyProvider)?
>
> Thanks again,
> Mark
>
>
>
> On Tue, Apr 2, 2019 at 10:35 PM Bryan Bende  wrote:
>
> > The initial admin policies are created here:
> >
> >
> > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595
> > <
> > https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595
> > >
> >
> > You can see where it will create the root group policies if rootGroupId is
> > not null.
> >
> > The rootGroupId comes from the parseFlow() method above which tries to
> > read the flow.xml.gz from disk, using the location from nifi.properties.
> >
> >
> > > On Apr 2, 2019, at 9:57 PM, Mark Bean  wrote:
> > >
> > > When NiFi is started for the first time, the Component Access Policies
> > are
> > > not populated even for the Initial Admin or for legacy DFM_ROLE users in
> > > authorized-users.xml file.That is, not unless a flow.xml.gz file exists.
> > > The fact that the admin user does not have access to these policies has
> > led
> > > to confusion for a great number of users.
> > >
> > > I believe this came up before and an explanation was given that since the
> > > flow.xml.gz does not yet exist (nor the root process group's UUID), the
> > > Component Access Policies cannot be created. However, I have to believe
> > > there is a mechanism that can be employed to return to policy generation
> > > after the flow.xml.gz is created.
> > >
> > > Can someone provide some pointers to where in the code I can look to see
> > > where the Global Policies are initially created and/or where Component
> > > Policies are created when migrating with an existing flow.xml.gz?
> > >
> > > Thanks,
> > > Mark
> >
> >

Re: initial component access policies

[Mark Bean]

Bryan,

Ok, thanks. Now, the issue is when there is no flow established yet. In
that case, FileAccessPolicyProvider.populateInitialAdmin will not find the
rootGroupId; it doesn't exist yet in cases where there is no flow.xml.gz on
startup. So, component access policies cannot be created.

The flow.xml.gz is initially created in StandardFlowService.load(DataFlow).
Here, the rootGroupId is known (or can be derived from the controller.)
However, at this point, there is no access to the FileAccessPolicyProvider
which is required to updated the policies. Hence, the problem of not
completing the authorizations (i.e. component policies) for an Initial
Admin User.

Do you have suggestions on how to access the FileAccessPolicyProvider (or
more generally a ConfigurableAccessPolicyProvider)?

Thanks again,
Mark



On Tue, Apr 2, 2019 at 10:35 PM Bryan Bende  wrote:

> The initial admin policies are created here:
>
>
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595
> <
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-file-authorizer/src/main/java/org/apache/nifi/authorization/FileAccessPolicyProvider.java#L595
> >
>
> You can see where it will create the root group policies if rootGroupId is
> not null.
>
> The rootGroupId comes from the parseFlow() method above which tries to
> read the flow.xml.gz from disk, using the location from nifi.properties.
>
>
> > On Apr 2, 2019, at 9:57 PM, Mark Bean  wrote:
> >
> > When NiFi is started for the first time, the Component Access Policies
> are
> > not populated even for the Initial Admin or for legacy DFM_ROLE users in
> > authorized-users.xml file.That is, not unless a flow.xml.gz file exists.
> > The fact that the admin user does not have access to these policies has
> led
> > to confusion for a great number of users.
> >
> > I believe this came up before and an explanation was given that since the
> > flow.xml.gz does not yet exist (nor the root process group's UUID), the
> > Component Access Policies cannot be created. However, I have to believe
> > there is a mechanism that can be employed to return to policy generation
> > after the flow.xml.gz is created.
> >
> > Can someone provide some pointers to where in the code I can look to see
> > where the Global Policies are initially created and/or where Component
> > Policies are created when migrating with an existing flow.xml.gz?
> >
> > Thanks,
> > Mark
>
>

Re: [DISCUSS] NiFi and Java 11

[Sivaprasanna]

Sounds good to me.

So contributors who bring in new changes are expected to write the code
that should be compatible with both Java 8 as well as Java 11, right?

Do we see anything that we should have in our site that would help the
contributors/users with this change? Something like a document that
explains best practices which a developer should follow so that the change
which the developer is bringing in should run fine in both 8 and 11.

-
Sivaprasanna

On Thu, 4 Apr 2019 at 12:18 AM, Pierre Villard 
wrote:

> Sounds good to me as well. Given the latest news on Java 8, having the 2
> PRs merged in would be great!
>
> Thanks,
> Pierre
>
> Le mer. 3 avr. 2019 à 20:34, Joe Witt  a écrit :
>
> > Jeff
> >
> > This seems very reasonable and thorough to me.
> >
> > The only short term implication that we'd have to buy into then is that
> PRs
> > going forward need to be able to build on both Java 8 and 11 which seems
> a
> > very fair way to bridge toward moving to Java 11 as the base requirement
> in
> > the next major release of NiFi (2.x).
> >
> > Thanks
> > Joe
> >
> > On Wed, Apr 3, 2019 at 2:19 PM Jeff  wrote:
> >
> > > I'm reaching out to the community today to propose a plan for moving
> > > forward with NiFi on Java 11.
> > >
> > > There are currently two PRs that deal with Java 11 compatibility.  The
> > > first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The
> > second
> > > PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There
> are
> > a
> > > lot of changes in the second PR, and it will require a lot of testing
> due
> > > to the breadth of changes from dependency upgrades.  Please take a look
> > at
> > > both of these PRs.  The earlier we can get feedback, the sooner we can
> > get
> > > Java 11 compatibility in an Apache NiFi release.
> > >
> > > I would to discuss with the community the following plan for upcoming
> > NiFi
> > > releases as they pertain to Java 11:
> > >
> > > For the 1.x release line, from either 1.10 or 1.11 (depending on when
> > these
> > > two PRs are merged to master) and onward, NiFi will be compatible with
> > both
> > > Java 8 and 11 for building and running NiFi:
> > >
> > >- Build on Java 8, run on Java 8
> > >- Build on Java 8, run on Java 11
> > >- Build on Java 11, run on Java 11
> > >
> > > The 1.x release line will contain convenience builds for Java 8, and
> will
> > > NOT contain convenience builds created from Java 11.  Users that want
> to
> > > run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build
> from
> > > the released source code.
> > >
> > > Once the Java 11 compatibility features [1] [2] are merged to master,
> PR
> > > reviews will require building and testing with Java 8 and Java 11
> before
> > > the PR is merged to master. We will add a new build to our Travis CI
> > > instance to cover building on Java 11, which should help with the PR
> > > process, since build status from Appveyor and Travis are shown on the
> PR.
> > > This will allow an easier transition to the NiFi 2.x release line.
> > >
> > > For the 2.x release line, the minimum Java version would be Java 11, at
> > > which point developers would be able to start using Java 11 language
> > > features.  Java 12 is not designated to be an LTS release, with its
> > support
> > > ending in September 2019.  I would not recommend making our minimum
> Java
> > > version a non-LTS Java release unless we are prepared to do NiFi
> releases
> > > to update the minimum Java version before the support for that version
> of
> > > Java ends.
> > >
> > > Taking this approach means we can reasonably allow users to run on Java
> > 11
> > > in the 1.x release line, ensure that we do not add commits which are
> not
> > > Java 11 compatible, and make it easier to transition into the 2.x line
> > for
> > > NiFi.
> > >
> > > - Jeff
> > >
> > > [1] https://github.com/apache/nifi/pull/3174
> > > [2] https://github.com/apache/nifi/pull/3404
> > >
> >
>

Re: [DISCUSS] NiFi and Java 11

[Pierre Villard]

Sounds good to me as well. Given the latest news on Java 8, having the 2
PRs merged in would be great!

Thanks,
Pierre

Le mer. 3 avr. 2019 à 20:34, Joe Witt  a écrit :

> Jeff
>
> This seems very reasonable and thorough to me.
>
> The only short term implication that we'd have to buy into then is that PRs
> going forward need to be able to build on both Java 8 and 11 which seems a
> very fair way to bridge toward moving to Java 11 as the base requirement in
> the next major release of NiFi (2.x).
>
> Thanks
> Joe
>
> On Wed, Apr 3, 2019 at 2:19 PM Jeff  wrote:
>
> > I'm reaching out to the community today to propose a plan for moving
> > forward with NiFi on Java 11.
> >
> > There are currently two PRs that deal with Java 11 compatibility.  The
> > first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The
> second
> > PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There are
> a
> > lot of changes in the second PR, and it will require a lot of testing due
> > to the breadth of changes from dependency upgrades.  Please take a look
> at
> > both of these PRs.  The earlier we can get feedback, the sooner we can
> get
> > Java 11 compatibility in an Apache NiFi release.
> >
> > I would to discuss with the community the following plan for upcoming
> NiFi
> > releases as they pertain to Java 11:
> >
> > For the 1.x release line, from either 1.10 or 1.11 (depending on when
> these
> > two PRs are merged to master) and onward, NiFi will be compatible with
> both
> > Java 8 and 11 for building and running NiFi:
> >
> >- Build on Java 8, run on Java 8
> >- Build on Java 8, run on Java 11
> >- Build on Java 11, run on Java 11
> >
> > The 1.x release line will contain convenience builds for Java 8, and will
> > NOT contain convenience builds created from Java 11.  Users that want to
> > run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build from
> > the released source code.
> >
> > Once the Java 11 compatibility features [1] [2] are merged to master, PR
> > reviews will require building and testing with Java 8 and Java 11 before
> > the PR is merged to master. We will add a new build to our Travis CI
> > instance to cover building on Java 11, which should help with the PR
> > process, since build status from Appveyor and Travis are shown on the PR.
> > This will allow an easier transition to the NiFi 2.x release line.
> >
> > For the 2.x release line, the minimum Java version would be Java 11, at
> > which point developers would be able to start using Java 11 language
> > features.  Java 12 is not designated to be an LTS release, with its
> support
> > ending in September 2019.  I would not recommend making our minimum Java
> > version a non-LTS Java release unless we are prepared to do NiFi releases
> > to update the minimum Java version before the support for that version of
> > Java ends.
> >
> > Taking this approach means we can reasonably allow users to run on Java
> 11
> > in the 1.x release line, ensure that we do not add commits which are not
> > Java 11 compatible, and make it easier to transition into the 2.x line
> for
> > NiFi.
> >
> > - Jeff
> >
> > [1] https://github.com/apache/nifi/pull/3174
> > [2] https://github.com/apache/nifi/pull/3404
> >
>

Re: [DISCUSS] NiFi and Java 11

[Joe Witt]

Jeff

This seems very reasonable and thorough to me.

The only short term implication that we'd have to buy into then is that PRs
going forward need to be able to build on both Java 8 and 11 which seems a
very fair way to bridge toward moving to Java 11 as the base requirement in
the next major release of NiFi (2.x).

Thanks
Joe

On Wed, Apr 3, 2019 at 2:19 PM Jeff  wrote:

> I'm reaching out to the community today to propose a plan for moving
> forward with NiFi on Java 11.
>
> There are currently two PRs that deal with Java 11 compatibility.  The
> first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The second
> PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There are a
> lot of changes in the second PR, and it will require a lot of testing due
> to the breadth of changes from dependency upgrades.  Please take a look at
> both of these PRs.  The earlier we can get feedback, the sooner we can get
> Java 11 compatibility in an Apache NiFi release.
>
> I would to discuss with the community the following plan for upcoming NiFi
> releases as they pertain to Java 11:
>
> For the 1.x release line, from either 1.10 or 1.11 (depending on when these
> two PRs are merged to master) and onward, NiFi will be compatible with both
> Java 8 and 11 for building and running NiFi:
>
>- Build on Java 8, run on Java 8
>- Build on Java 8, run on Java 11
>- Build on Java 11, run on Java 11
>
> The 1.x release line will contain convenience builds for Java 8, and will
> NOT contain convenience builds created from Java 11.  Users that want to
> run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build from
> the released source code.
>
> Once the Java 11 compatibility features [1] [2] are merged to master, PR
> reviews will require building and testing with Java 8 and Java 11 before
> the PR is merged to master. We will add a new build to our Travis CI
> instance to cover building on Java 11, which should help with the PR
> process, since build status from Appveyor and Travis are shown on the PR.
> This will allow an easier transition to the NiFi 2.x release line.
>
> For the 2.x release line, the minimum Java version would be Java 11, at
> which point developers would be able to start using Java 11 language
> features.  Java 12 is not designated to be an LTS release, with its support
> ending in September 2019.  I would not recommend making our minimum Java
> version a non-LTS Java release unless we are prepared to do NiFi releases
> to update the minimum Java version before the support for that version of
> Java ends.
>
> Taking this approach means we can reasonably allow users to run on Java 11
> in the 1.x release line, ensure that we do not add commits which are not
> Java 11 compatible, and make it easier to transition into the 2.x line for
> NiFi.
>
> - Jeff
>
> [1] https://github.com/apache/nifi/pull/3174
> [2] https://github.com/apache/nifi/pull/3404
>

[DISCUSS] NiFi and Java 11

[Jeff]

I'm reaching out to the community today to propose a plan for moving
forward with NiFi on Java 11.

There are currently two PRs that deal with Java 11 compatibility.  The
first PR allows NiFi built on Java 8 to be run on Java 11 [1].  The second
PR allows NiFi to be built on Java 11 and run on Java 11 [2].  There are a
lot of changes in the second PR, and it will require a lot of testing due
to the breadth of changes from dependency upgrades.  Please take a look at
both of these PRs.  The earlier we can get feedback, the sooner we can get
Java 11 compatibility in an Apache NiFi release.

I would to discuss with the community the following plan for upcoming NiFi
releases as they pertain to Java 11:

For the 1.x release line, from either 1.10 or 1.11 (depending on when these
two PRs are merged to master) and onward, NiFi will be compatible with both
Java 8 and 11 for building and running NiFi:

   - Build on Java 8, run on Java 8
   - Build on Java 8, run on Java 11
   - Build on Java 11, run on Java 11

The 1.x release line will contain convenience builds for Java 8, and will
NOT contain convenience builds created from Java 11.  Users that want to
run NiFi 1.1x.y on Java 11 with Java 11 bytecode will have to build from
the released source code.

Once the Java 11 compatibility features [1] [2] are merged to master, PR
reviews will require building and testing with Java 8 and Java 11 before
the PR is merged to master. We will add a new build to our Travis CI
instance to cover building on Java 11, which should help with the PR
process, since build status from Appveyor and Travis are shown on the PR.
This will allow an easier transition to the NiFi 2.x release line.

For the 2.x release line, the minimum Java version would be Java 11, at
which point developers would be able to start using Java 11 language
features.  Java 12 is not designated to be an LTS release, with its support
ending in September 2019.  I would not recommend making our minimum Java
version a non-LTS Java release unless we are prepared to do NiFi releases
to update the minimum Java version before the support for that version of
Java ends.

Taking this approach means we can reasonably allow users to run on Java 11
in the 1.x release line, ensure that we do not add commits which are not
Java 11 compatible, and make it easier to transition into the 2.x line for
NiFi.

- Jeff

[1] https://github.com/apache/nifi/pull/3174
[2] https://github.com/apache/nifi/pull/3404

Re: Reg:Nifi registery

[Kevin Doran]

Hi Prashanth,

By default, NiFi Registry stores all data (flows, metadata, etc) in
sub directories of its home directory (the install dir, which has sub
dirs such as /conf, /lib, and /bin), so as long as you are taking
regular backups of that directory you should be able to restore from a
backup.

An alternative approach some people use is to use the
GitFlowPersistenceProvider configured with a remote git repository,
which means every flow is also synced to a remote github repository.
This backup of flows can be used for disaster recovery in a few ways:
- not released yet, but on master coming in the next release is a
feature that will repopulate NiFi Registry's metadata directory from a
git repository on startup
- scripted using a tool such as the NiFi CLI, included in the NiFi Toolkit
- some other approaches people have come up with, for example docker
images with additional scripts that let a Registry container be
initialized from a git repo and I believe there is a PR open now that
adds additional capabilities to a git-backed Registry.

Hope this helps! Let us know if you have additional questions.

Kevin

On Wed, Apr 3, 2019 at 8:28 AM Prashanth Reddy
 wrote:
>
> Hi
>
> i am much interested in working with nifi and registry.but i am unable to
> find backing up stored flows and how to reuse them when new registry
> crashes (old one system crashes).
>
> Best Regards,
> Prashanth

Reg:Nifi registery

[Prashanth Reddy]

Hi

i am much interested in working with nifi and registry.but i am unable to
find backing up stored flows and how to reuse them when new registry
crashes (old one system crashes).

Best Regards,
Prashanth