Joe, I just filed a BUG Jira [1]. It’s a bit of a corner case, but when it occurs it can cause a pretty big problem. Should have a fix up very shortly. Will leave it up to you whether or not you think we should get this into 1.14.0.
Thanks -Mark [1] https://issues.apache.org/jira/browse/NIFI-8771 On Jul 8, 2021, at 10:26 AM, Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: Team, The 1.14 RC1 build is underway. Hopefully I will email artifacts today. Reminder this should now generate convenience binaries for nifi, stateless nifi, minifi java, nifi registry and the associated toolkits all in a single release process which also keeps these things in sync. Please do not tag any further fix versions to 1.14.0. Use 1.15.0 from here. I'll pull things in if RCs fail/etc. Thanks On Tue, Jul 6, 2021 at 8:21 AM Joe Witt <joe.w...@gmail.com<mailto:joe.w...@gmail.com>> wrote: Team Going to try to pull the rc together today. Havent looked at what remains but it is time. Will look at what is hanging out/mergable and get after it. Thanks On Thu, Jun 24, 2021 at 8:45 AM Nathan Gough <thena...@gmail.com<mailto:thena...@gmail.com>> wrote: Joe Gresock just pinged me about an issue that may have been introduced by a dependency upgrade I did for lucene: https://issues.apache.org/jira/browse/NIFI-8699 which appears to cause an issue for existing provenance repositories. I tested the upgrade on a fresh install so I didn't notice the issue. There appears to be a way to add a backwards codec which should allow the new lucene to keep working with the existing provenance repo. Looking into reproducing and a fix for it now. On Wed, Jun 23, 2021 at 9:06 AM Mark Bean <mark.o.b...@gmail.com<mailto:mark.o.b...@gmail.com>> wrote: Putting out one more request for the following open PR's before 1.14 https://github.com/apache/nifi/pull/5094 https://github.com/apache/nifi/pull/5061 Both have been reviewed, but still need attention from a comitter. Thanks! -Mark On Mon, Jun 21, 2021 at 12:17 PM Joe Witt <joe.w...@gmail.com> wrote: Team, I'll start pulling 1.14 together more this week as time permits. As far as specific commits/etc.. please work with reviewers/etc.. to help nail that down. If anything doesn't make it in when I initiate the RC line then we'll get it on the next one. There is a shocking amount of goodness in here already. Thanks On Sun, Jun 13, 2021 at 2:27 PM Chris Sampson <chris.samp...@naimuri.com.invalid> wrote: Joe, Yeah I thought it would be something like that (but didn't spend time looking at the moment, just thought I'd highlight the thread). Don't know whether there's anything to consider adding to/clarifying in the documentation in order to highlight that to (first time) users? Again, I figured this would probably be "as designed" and I've not spent the time reading the docs for this new default behaviour - so long as it should be clear to first time users (provided they read the docs), then all good. Cheers, Chris Sampson On Sun, 13 Jun 2021, 21:42 Joe Witt, <joe.w...@gmail.com> wrote: Chris I responded to the slack thread. Pretty sure it is doing exactly what is expected. We are not offering a user management and policy authoring experience for that. It is quite literally 'single user auth' and in that mode this single user we generate has all the authorizations. This is functionally equivalent to how it was with an unsecured instance with what is basically 'anonymous' user except in this case it is TLS and requires the known single user credentials. For real usage, just as before, users need to take advantage of one of the other existing authentication and authorization plugin options. Thanks On Sun, Jun 13, 2021 at 11:26 AM Chris Sampson <chris.samp...@naimuri.com.invalid> wrote: FYI, there's a new thread in slack about the new single-user-authoriser setup - user has https but no users/policy screen for setting up AuthZ. Might be worth someone taking a look before an RC to see whether there's documentation (or functionality) that needs clarifying. Cheers, Chris Sampson On Sun, 13 Jun 2021, 13:57 Mark Bean, <mark.o.b...@gmail.com> wrote: There are three open PR's I would appreciate some eyes on before the RC process is kicked off. Two of the three have been reviewed, but not yet by a committer. https://github.com/apache/nifi/pull/5094 https://github.com/apache/nifi/pull/5061 https://github.com/apache/nifi/pull/5064 Thanks in advance! -Mark On Fri, Jun 11, 2021 at 4:05 PM Joe Witt <joe.w...@gmail.com> wrote: So. Dang. Cool. I just built from latest main and poof - I'm on https with username/password. Will start whipping up the process for an RC. Probably will be a little slow going with dayjob factors but will get on it. Thanks On Fri, Jun 11, 2021 at 12:14 PM David Handermann <exceptionfact...@apache.org> wrote: Thanks to Mark Payne, NIFI-8516 is now merged, so that covers current open issues around securing the default configuration. Regards, David Handermann On Fri, Jun 11, 2021 at 11:55 AM David Handermann < exceptionfact...@apache.org> wrote: Joe, Thanks for following up. The PR for NIFI-8516 has gone through several rounds of feedback, I believe it is about ready to go, pending confirmation that the ability to set custom credentials addresses the ease of use concern. Regards, David Handermann On Fri, Jun 11, 2021 at 11:41 AM Joe Witt < joe.w...@gmail.com> wrote: David, Ok thanks - do you have a sense of when what you see as good 1.14 specific work will be merged? Do you have the reviewers/engagement you need? This 1.14 is already pretty packed but definitely agree we need to make real progress on secure by default and this release is a great time to take the first big step. Thanks On Mon, May 31, 2021 at 5:52 AM David Handermann <exceptionfact...@apache.org> wrote: Thanks for kicking off the discussion Joe! Of the many items that could be included in the next release, securing the default configuration as described in NIFI-8220 <https://issues.apache.org/jira/browse/NIFI-8220> would be great to have completed. Most of the elements are in place, and the current Pull Request for NIFI-8516 <https://github.com/apache/nifi/pull/5068 is under review. If there are any other achievable items that should be included as part of a secure default installation for NiFi, it would be helpful to add sub-tasks to NIFI-8220. The current scope is limited to a standalone installation, so issues regarding clustered deployments can be handled separately. If others are interested in evaluating the proposed new default configuration that requires HTTPS and leverages a generated username and password, feel free to provide feedback on NIFI-8516. Regards, David Handermann On Thu, May 27, 2021 at 6:51 PM Otto Fowler < ottobackwa...@gmail.com> wrote: I think NIFI-8625 and NIFI-8461 need to be understood and addressed. On May 27, 2021, at 13:29, Joe Witt < joe.w...@gmail.com> wrote: Team, There has been a tremendous amount of work already on the 1.14 line as shown: https://issues.apache.org/jira/projects/NIFI/versions/12349644 These include merging the nifi registry and minifi java into the nifi line itself. So when we release these things stay in sync and maintained. The release will now produce things like Apache NiFi, the Apache NiFi toolkit, Apache NiFi Registry, and Apache NiFi MiNiFi Java and the Apache NiFi stateless runtime as well. There have been many improvements to core nifi and stateless nifi now meaning we have the traditional execution form factor and this new stateless mode. We can now hot load nars from HDFS storage locations which could mean HDFS, blob storage in the cloud, etc.. There is a lot more. Anyway, I wanted to start circling the wagons for a 1.14 release. I'm happy to take on RM duties especially since there will be new elements to the release process. Thanks
