, since the EncryptContent Processor is deprecated and
removed from NiFi 2.0.0.
Regards,
David Handermann
On Thu, Apr 11, 2024 at 10:26 AM Jim Steinebrey wrote:
>
> Hi Cecil,
> In response to your questions,
> if you store credentials in the contents of an encrypted flow file, then the
&
libraries, I would not
expect CentOS 7 to be supported for building NiFi 2.0.
Regards,
David Handermann
[1] https://lists.apache.org/thread/jdmw7dsjryyf8vbjgq84tl8kpv68pplr
[2] https://www.redhat.com/en/topics/linux/centos-linux-eol
On Fri, Apr 19, 2024 at 10:51 AM Dan S wrote:
>
> I am trying to
Dan,
Reviewing recent changes, NIFI-13035 [1] updated the frontend build
process to use Node.js 21 for both the current nifi-web-ui and the new
nifi-web-frontend modules. For that reason, a more recent OS and glibc
version is now required.
Regards,
David Handermann
[1] https://issues.apache.org
Mike,
The change was intentional from my understanding as Node.js 16 reached
end of life last year [1]. Registry should also be updated to build
with a more recent version of Node.js, but I believe there are some
details to sort out before that can be changed.
Regards,
David Handermann
[1
glad to handle Release Manager responsibilities for
2.0.0-M3 when things are ready.
Regards,
David Handermann
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%202.0.0-M3
[2] https://github.com/apache/nifi/pull/8677
[3] https://issues.apache.org/jira
,
David Handermann
On Tue, Apr 23, 2024 at 2:42 PM Matt Gilman wrote:
>
> I agree. Including the updated UI and getting some feedback would be great.
>
> On Mon, Apr 22, 2024 at 8:50 PM Joe Witt wrote:
>
> > Id be a big fan of including the new UI.
> >
> > On Mo
more of those issues resolved should put things in a good
position.
Regards,
David Handermann
On Wed, Apr 24, 2024 at 8:32 AM Joe Witt wrote:
>
> Also agreed there. Profile should be there to exclude perhaps but include
> should be default.
>
> On Wed, Apr 24, 2024 at 6:30 AM D
+1 binding
- Verified signatures and hashes
- Ran build using Maven Wrapper 3.9.6
- Ran build on Ubuntu 22.04 with Azul Zulu JDK 1.8.0-382 x86_64
Thanks Pierre!
Regards,
David Handermann
On Fri, May 3, 2024 at 7:47 AM Pierre Villard
wrote:
>
> Team,
>
> I am pleased to be calli
Joe,
Thanks for highlighting the Kafka Connect external module. I concur
with your evaluation, I have not observed community usage or
questions, so it seems best to remove from the main branch.
Regards,
David Handermann
On Tue, May 7, 2024 at 2:18 PM Otto Fowler wrote:
>
> I would say n
Joe,
Thanks for highlighting these areas to be updated. I was able to
address the QuestDB update with a couple minor adjustments, and
submitted a PR [1].
Regards,
David Handermann
[1] https://github.com/apache/nifi/pull/8773
On Tue, May 7, 2024 at 2:58 PM Chris Sampson
wrote:
>
> I’ll p
.
Regards,
David Handermann
On Fri, May 3, 2024 at 4:02 AM Pierre Villard
wrote:
>
> I'm starting the process for the 1.26 RC as I don't believe we're waiting
> for any additional PRs there.
>
> Le jeu. 2 mai 2024 à 07:30, Joe Witt a écrit :
>
> > Matt
> &g
Team,
We have had great progress this week on a number of important details.
At this point, I am planning on starting the release candidate build
process first thing next week.
Regards,
David Handermann
On Tue, May 7, 2024 at 4:09 PM David Handermann
wrote:
>
> Team,
>
> Ther
Team,
I am pleased to be calling this vote for the source release of Apache
NiFi 2.0.0-M3.
Please review the following guide for how to verify a release candidate build:
https://cwiki.apache.org/confluence/display/NIFI/Release+Candidate+Verification
The source being voted on and the convenience
+1 binding
On Mon, May 13, 2024 at 10:48 PM David Handermann
wrote:
>
> Team,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi 2.0.0-M3.
>
> Please review the following guide for how to verify a release candidate build:
>
> https://
Apache NiFi Community,
I am pleased to announce that the 2.0.0-M3 release of Apache NiFi passes:
9 +1 (binding) votes
10 +1 (non-binding) votes
0 0 votes
0 -1 votes
Thanks to all who helped make this release possible!
The release artifacts will be published in the next 24 hours.
The Apache NiFi Team is pleased to announce the release of Apache NiFi 2.0.0-M3.
Apache NiFi is an easy to use, powerful, and reliable system to
process and distribute data.
https://nifi.apache.org
The release artifacts can be downloaded from the project website.
https://nifi.apache.org/downloa
Thanks Pierre, sounds good!
Regards,
David Handermann
On Tue, May 21, 2024 at 8:36 AM Pierre Villard
wrote:
>
> Thanks will go ahead with 1.6.0 release process
>
> Le lun. 20 mai 2024 à 19:30, Matt Burgess a écrit :
>
> > +1 for a 1.6.0 release
> >
> > On M
, however, that
should be handled before the release process.
If there are no breaking changes, I recommend a version 1.6.0 release
before a 2.0.0 release of the plugin.
Regards,
David Handermann
On Tue, May 21, 2024 at 10:19 AM Pierre Villard
wrote:
>
> Given that the flow analysis rul
Pierre,
Thanks for clarifying. I agree that going to Java 21 makes sense, and
aligns with the NiFi main branch. That would be a breaking change,
warranting the 2.0.0 version, so that sounds like a good plan.
Regards,
David Handermann
On Tue, May 21, 2024 at 10:32 AM Pierre Villard
wrote
better foundation for integration than the
purpose-built components that support the current ListenUDP Processor.
Regards,
David Handermann
[1] https://netty.io/wiki/user-guide-for-4.x.html
[2]
https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-extension-utils/nifi-event
,
David Handermann
[1] https://issues.apache.org/jira/projects/NIFI/versions/12354651
the main repository.
I can proceed along these lines, unless any substantive objections come up,
and the pull request process will also provide opportunity for additional
consideration and review.
Regards,
David Handermann
[1] https://lists.apache.org/thread/nok561sg1dzw3zrott06gkl34hdjxbb3
On
are in a good position for an
initial release candidate build.
Regards,
David Handermann
[1] https://github.com/apache/nifi/pull/8974
[2] https://github.com/apache/nifi/pull/9000
On Mon, Jun 17, 2024 at 11:12 AM Shane Ardell wrote:
>
> Hi team,
>
> Pierre is correct that I'm ai
decoupled Python
Processor development efforts.
Regards,
David Handermann
[1] https://github.com/apache/nifi-python-extensions
[2] https://hatch.pypa.io
On Sat, Jun 22, 2024 at 9:06 AM David Handermann
wrote:
>
> Joe,
>
> Thanks for raising the discussion, and thanks to everyone for
Team,
I am pleased to be calling this vote for the source release of Apache
NiFi 2.0.0-M4.
Please review the following guide for how to verify a release candidate build:
https://cwiki.apache.org/confluence/display/NIFI/Release+Candidate+Verification
The source being voted on the and the conveni
+1 (binding)
On Fri, Jun 28, 2024 at 8:40 AM David Handermann
wrote:
>
> Team,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi 2.0.0-M4.
>
> Please review the following guide for how to verify a release candidate build:
>
> https://
vote thread:
https://lists.apache.org/thread/jdb2j398ow6221rx4og7p958nnbj7bs9
Regards,
David Handermann
The Apache NiFi Team is pleased to announce the release of Apache NiFi 2.0.0-M4.
Apache NiFi is an easy to use, powerful, and reliable system to
process and distribute data.
https://nifi.apache.org
The release artifacts can be downloaded from the project website.
https://nifi.apache.org/downloa
Thanks Pierre!
Regards,
David Handermann
On Wed, Jul 3, 2024 at 7:42 AM Pierre Villard
wrote:
>
> Team,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> 1.27.0.
>
> Please review the following guide for how to verify a release candida
believe we are on a solid path
forward. When we focus on specific concerns, such as those Pierre
raised regarding Kafka or Kudu, we can incorporate solutions as we go
forward.
Regards,
David Handermann
[1] https://issues.apache.org/jira/browse/NIFI-13494
On Sun, Jul 7, 2024 at 11:44 PM Joe Witt wrote
Apache NiFi is an easy to use, powerful, and reliable system to
process and distribute data.
https://nifi.apache.org
The release artifacts can be downloaded from the project website.
https://nifi.apache.org/download/
Maven artifacts have been released and mirrored according to ASF
artifact dist
aspects. However, NiFi 2.0
presents an important step forward on a number of levels. Tracking and
addressing issues with the new Kafka components should provide the
best path for maintainability.
Regards,
David Handermann
On Mon, Jul 8, 2024 at 9:08 AM Paul Grey wrote:
>
> >
> > K
related to continued maintenance of a problematic
implementation.
Regards,
David Handermann
[1] https://github.com/apache/nifi/pull/9039
On Thu, Jul 18, 2024 at 1:49 PM Matt Burgess wrote:
>
> Couldn't we restore the encrypted repository implementation as a NAR and
> possibly ma
, and any changes to those files will have
direct implications for the security of the installation. If you have any
additional background on the intended use case for NiFi with FIPS support,
that may be helpful to know.
Regards,
David Handermann
On Sat, Jul 20, 2024 at 3:21 PM William Mallett
their own images to add pip, it follows the general
principle of providing secure defaults. There is a developer usability
tradeoff, but we have had similar considerations in the past, and have
leaned in the direction of security.
Regards,
David Handermann
question is to consider the
default distribution approach, allowing users to make further
decisions.
Regards,
David Handermann
On Wed, Jul 24, 2024 at 6:51 PM Matthew Hawkins wrote:
>
> Hi David,
>
> See the RHEL bug [1] for the shellacking this now rescinded CVE received.
>
> Rem
road.
With that background, as soon as we are in a good position with the
content viewer integration, we should proceed to preparing for a
release.
Regards,
David Handermann
[1] https://issues.apache.org/jira/browse/NIFI-13632
On Thu, Aug 8, 2024 at 5:57 PM Arpad Boda wrote:
>
page, outlining the recommended steps in
more detail so we can come to consensus on how this should work.
Regards,
David Handermann
[1]
https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
[2] https://cwiki.apache.org/confluence/display/NIFI/NiFi+Feature+Proposals
Thanks for the replies!
I will move forward with drafting a NiFi Improvements Proposal page to
keep the discussion going.
Regards,
David Handermann
On Tue, Aug 20, 2024 at 3:22 PM Mark Payne wrote:
>
> David,
>
> +1 to all of this. Especially for guaranteeing compa
instituting the Improvement Proposal Process. If this proves to be too
much of a concern, we can divide the question and vote separately on
the Improvement Proposal Process and moving the nifi-api.
Thanks for the feedback!
Regards,
David Handermann
On Wed, Aug 21, 2024 at 11:09 AM David Handermann
proceed to create the new Jira project for NiFi Improvement
Proposals and the Git repository for nifi-api.
Here is the vote thread:
https://lists.apache.org/thread/59o0d9cv4mo4g5hpr8fprtkh6dt7c953
Regards,
David Handermann
mment, I have another open issue that is closely related to S/MIME
handling, and includes some Controller Services that could be useful in
implementing signed S/MIME emails. Feel free to provide your comments on
the related issue and PR in GitHub.
Regards,
David Handermann
On Tue, Dec 1, 2020 at
,
David Handermann
On Fri, Jan 29, 2021 at 5:33 PM M Tien wrote:
> +1 non-binding.
>
> Went through the release guide
> Verified a full build on JDK 1.8.0_275 and JDK 11.0.5
> Verified a secure instance of NiFi
> Verified I was able to authenticate with OIDC using Google, Okta, and
as well as TLS protocol
support differences on Java 8 and 11.
Confirmed absence of bcprov-ext-jdk15on from nifi-framework-nar as
documented in NIFI-8186.
Regards,
David Handermann
On Tue, Feb 2, 2021 at 12:18 PM Mark Payne wrote:
> +1 (binding)
>
> Build details:
> Apache
out a full understanding of the configuration
required, so it is important to keep the audience in mind when evaluating a
solution.
Regards,
David Handermann
On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende wrote:
> Just to clarify, I was not suggesting that we make a default secure
> setup th
concerns with password authentication can be mitigated with one-way TLS, so
a blending of these approaches, as Joe describes in NIFI-8220, seems like a
good way to go.
Regards,
David Handermann
On Wed, Feb 10, 2021 at 8:23 AM Mark Payne wrote:
> I would be in favor of this as well. I agree t
Mark,
Thanks for clarifying, that makes sense.
Regards,
David Handermann
On Wed, Feb 10, 2021 at 8:41 AM Mark Payne wrote:
> David,
>
> My concern was purely around generating client certs and using mutual TLS.
> I definitely think we should have a server cert if using username
Twitter post, this
general discussion is more of a reflection of the need to make things more
secure by default as other products have followed similar approaches.
Regards,
David Handermann
On Wed, Feb 10, 2021 at 8:53 AM Kevin Doran wrote:
> I am in favor of requiring some authentication
ikely to have a publicly addressable DNS name, so Let's Encrypt is not an
option in those cases.
Regards,
David Handermann
On Wed, Feb 10, 2021 at 11:09 AM Joe Witt wrote:
> Otto
>
> Installers like you mention are inherently brutal for portability so very
> difficult for us i
default nifi.properties.
Configured and tested mutual TLS authentication on a standalone server with
BCFKS key store and trust store.
Regards,
David Handermann
On Fri, Feb 12, 2021 at 5:45 PM Muazma Zahid wrote:
> +1 (non-binding)
>
> - Ran build with OpenJDK 1.8.0_275 on Linux
> - Depl
+1 non-binding
Verified release signatures and expected files.
Verified build on Ubuntu 20.10 using Apache Maven 3.6.3 with Azul Zulu JDK
11.0.10.
Configured and tested InvokeHTTP with multiple configurations including
disabling HTTP/2.
Regards,
David Handermann
On Fri, Mar 12, 2021 at 2:19 PM
+1 non-binding
- Verified release signatures and expected files
- Verified build on Ubuntu 20.10 using Apache Maven 3.6.3 with Azul Zulu
JDK 11.0.10
- Verified Admin Guide update for NIFI-8324
- Verified valid JSON output from SplitJson for NIFI-8342
Regards,
David
On Thu, Mar 18, 2021 at 1:09 P
timeout setting as the Linux and macOS builds? Introducing one would at
least kill off problematic Windows builds.
Regards,
David Handermann
On Mon, Apr 19, 2021 at 10:08 AM Joe Witt wrote:
> Thanks for bringing this up. The most clear next step I can envision
> at this point is that we br
project-list command line options
should support building both a module and its dependencies. The list of
changes files can be passed to another action that could determine one or
more modules to build.
Regards,
David Handermann
On Mon, Apr 19, 2021 at 12:56 PM Chris Sampson
wrote:
>
Congratulations Chris! Looking forward to your continued contributions!
Regards,
David Handermann
On Thu, May 13, 2021 at 3:38 PM Matt Burgess wrote:
> Congratulations and welcome aboard Chris!
>
> On Thu, May 13, 2021 at 4:25 PM Joe Witt wrote:
> >
> > On behalf of the
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.
Re
Names should resolve the problem.
Here's the release notes for OkHttp 3.10.0, referencing RFC 2818, which
deprecated falling back to certificate common names for hostname
verification:
https://square.github.io/okhttp/changelog_3x/#version-3100
Regards,
David Handermann
On Thu, Jun 10, 2021
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
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.
:
https://issues.apache.org/jira/browse/NIFI-6714
Regards,
David Handermann
On Sat, Jun 12, 2021 at 10:31 AM MaHmOuD El-Sayed
wrote:
> .bootstrap.config.log.dir=C:\Users\MaHmOuD\DOWNLO~1\COMPRE~1\NIFI-1~1.2\bin\..\\logs
> org.apache.nifi.NiFi
> Exception in thr
repository password property
- Tested NiFi Registry with bucket creation and NiFi process group version
control
- Test NiFi Stateless with GetFile and UnpackContent flow downloaded from
NiFi process group
Regards,
David Handermann
On Mon, Jul 12, 2021 at 6:31 AM Arpad Boda wrote:
> +1 (bind
Chad,
Can you provide the output of the test failures, specifically which unit
tests failed and any associated error messages? That would help narrow
down the potential source of the problem.
Regards,
David Handermann
On Mon, Jul 12, 2021 at 9:05 PM Chad Zobrisky wrote:
> Anyone else hav
Thanks for handling this, Matt. As one of the reviewers on the PR, I vote
+1 (non-binding).
Regards,
David Handermann
On Fri, Jul 16, 2021 at 1:20 PM Matt Burgess wrote:
> All,
>
> We've been asked to record our consensus for the move of NiFi Registry
> to the NiFi codebase
consideration. Many of you have been
developing NiFi for years and I look forward to your feedback. I would be
glad to put together a more formalized recommendation on Confluence and
write up Jira epics if this general approach sounds agreeable to the
community.
Regards,
David Handermann
and new commits applied
selectively?
Regards,
David Handermann
On Fri, Jul 23, 2021 at 11:29 AM Matt Burgess wrote:
> 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
is better in terms of what should be covered under
the general heading of technical debt reduction.
Regards,
David Handermann
On Fri, Jul 23, 2021 at 12:11 PM Russell Bateman
wrote:
> Bringing up Elastic also reminds me that the Elastic framework has just
> recently transitioned out o
definitely help with future maintenance.
Regards,
David Handermann
On Sat, Jul 24, 2021 at 10:57 AM Mark Payne wrote:
> There’s also some code that exists in order to maintain backward
> compatibility in the repositories. I would very much like the repositories
> to contain no unnecessary
component
properties, upgrading the AWS SDK could be worked independently. Others may
have more insight into particular usage of that library.
Regards,
David Handermann
On Sun, Jul 25, 2021 at 2:12 AM Chris Sampson
wrote:
> Might be worth considering refactoring the build as part of this work too
documentation includes the contents of the DeprecationNotice for
PostHTTP:
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.14.0/org.apache.nifi.processors.standard.PostHTTP/index.html
Regards,
David Handermann
On Tue, Jul 27, 2021 at 9:56 AM Mark Bean wrote
it obvious and making
it something that ends up getting ignored.
Regards,
David Handermann
On Tue, Jul 27, 2021 at 10:28 AM Mark Bean wrote:
> I'll start a new thread for PostHTTP when I get a template and/or detailed
> stats.
>
> I know the deprecation is noted in the docume
that level, but at least for version 2, maintaining component API
compatibility is key.
Regards,
David Handermann
On Sun, Aug 1, 2021 at 10:23 AM Mark Bean wrote:
> I created a JIRA ticket to investigate and improve the performance of
> InvokeHTTP. It includes a flow definition for benchm
ed testing is vital to the continued health of the project,
so thanks to everyone who contributes to the testing process!
Regards,
David Handermann
rties. I would be glad to help with the migration
process, but it would be helpful to avoid having to revisit code multiple
times to address these issues.
Regards,
David Handermann
On Wed, Aug 25, 2021 at 2:24 PM Mike Thomsen wrote:
> I broke up the tickets because it is A LOT of individu
s like the best use of everyone's time. Thanks for the consideration.
Regards,
David Handermann
On Fri, Aug 27, 2021 at 11:12 AM Mike Thomsen
wrote:
> Some responders seem to prefer a batched migration while others have
> suggested a massive PR that does all of the low-hanging fruit in
Tim,
Thanks for highlighting the updated PR, I provided some feedback and would
be glad to help move it forward.
Regards,
David Handermann
On Fri, Sep 3, 2021 at 5:18 AM Smith, Tim wrote:
> The author submitted a new pull request for ValidateJSON:
> https://github.com/apache/nifi/pul
Thank you all for the congratulations! After using NiFi for several years,
it is great to be able to contribute back. I look forward to continued
involvement on a great project with a great group of collaborators!
Regards,
David Handermann
On Fri, Sep 17, 2021 at 4:25 PM Joe Witt wrote:
>
existing multi-tenant integration
options cover a wide variety of deployment patterns, but feel free to
highlight potential gaps.
Regards,
David Handermann
On Wed, Sep 29, 2021 at 11:57 AM Michael Radov (RIT Alumni)
wrote:
> Hey,
>
> Hope all is well. Is there a way to have a future v
-1 (binding)
Reproduced the failing system tests described in NIFI-9352. Verified many
other features are working as designed, but I agree that this is a blocker
for the current release candidate version.
Regards,
David Handermann
On Sat, Oct 30, 2021 at 9:26 AM Mark Payne wrote:
>
nning NiFi
container:
docker run --name nifi -p 8443:8443 apache/nifi:1.15.0-dockermaven
If you are still having issues, it would be helpful to provide any logs or
error messages you are seeing.
Regards,
David Handermann
On Thu, Nov 4, 2021 at 8:10 PM Kevin Doran wrote:
> Oh meant to send a
Verified JoltTransformJSON custom UI works as expected
Thanks for managing the release process Joe!
Regards,
David Handermann
On Thu, Nov 4, 2021 at 6:33 PM Matt Burgess wrote:
> +1 Release this package as nifi-1.15.0
>
> Ran through the release helper and some tests to verify various Jir
Thanks for the update Chris!
I agree with the suggestion to streamline the Dockerfiles for NiFi builds,
there is a lot of duplication between dockermaven and dockerhub, so
unifying the modules and parameterizing necessary differences would be a
helpful improvement.
Regards,
David Handermann
On
+1 (binding)
- Built nifi-nar-maven-plugin 1.3.3 on Azul Zulu 11.0.10
- Built NiFi using nifi-nar-maven-plugin 1.3.3
- Verified contents of selected extension-manifest.xml files
Thanks for managing the release Bryan!
Regards,
David Handermann
On Thu, Dec 2, 2021 at 8:10 AM Pierre Villard
allow the
OIDC configuration to load as expected in NiFi 1.14.0.
Regards,
David Handermann
On Wed, Dec 8, 2021 at 4:54 AM Ganesh, B (Nokia - IN/Bangalore) <
b.gan...@nokia.com> wrote:
> Hi ,
>
>
>
> We are using apache nifi 1.14 . We have 3 nodes in nifi cluster , cluste
Joe,
Thanks for starting this discussion. Moving forward with a 1.15.1 patch
release sounds like the best path forward.
Regards,
David Handermann
On Mon, Dec 13, 2021 at 7:49 AM Joe Witt wrote:
> Team
>
> We still dont think we are vulnerable but this now highly risky library is
,
David Handermann
On Mon, Dec 13, 2021 at 10:44 AM Chris Sampson
wrote:
> I'd agree. The discussions in Slack and separate user mailing list thread
> are a reassurance for users (who read them), but a patch for the current
> 1.15 branch would seem sensible for people to pick up a
permits.
https://issues.apache.org/jira/browse/NIFI-8630
Regards,
David Handermann
On Tue, Dec 14, 2021 at 7:52 AM sanjeet rath wrote:
> Hi
>
> The latest 1.15 Nifi version contain mail-1.4.7.jar file(inside
> \lib\bootstrap folder).
> We r using 1.12.1 version of nifi same issu
Congratulations Margot!
On Wed, Dec 15, 2021 at 2:50 PM Nathan Gough wrote:
> Congrats Margot, thanks for all your contributions!
>
> On Wed, Dec 15, 2021 at 3:02 PM Chris Sampson
> wrote:
>
> > Congrat Margot!
> >
> > ---
> > *Chris Sampson*
> > IT Consultant
> > chris.samp...@naimuri.com
> >
-sensitive-properties-key
command. If you want to change the algorithm to the new default of
NIFI_PBKDF2_AES_GCM_256, then you can use the encrypt-config.sh toolkit
command described.
Regards,
David Handermann
On Tue, Dec 21, 2021 at 4:43 PM Joe Witt wrote:
> Phil
>
> Not sure if this
- NIFI-9509 Verified successful SFTP retrieval and renaming using AWS
Transfer Family SFTP Server as well as Linux OpenSSH Server
Thanks for the quick turnaround on this release Joe!
Regards,
David Handermann
On Tue, Dec 21, 2021 at 8:19 PM Mark Payne wrote:
> +1 (binding)
>
> Verifi
/1.15.2/org.apache.nifi.proxy.StandardProxyConfigurationService/index.html
Regards,
David Handermann
On Thu, Jan 13, 2022 at 12:39 PM sanjeet rath
wrote:
> Hi,
>
> I encounter one "java.net.NoRouteToHostException: No route to host (Host
> unreachable)" in *Nifi UI logi
n the best approach is to integrate the
ProxyConfigurationService and determine how that should be wired to your
custom component library.
Regards,
David Handermann
On Thu, Jan 13, 2022 at 1:02 PM sanjeet rath wrote:
> Thanks a lot for the quick response.
>
> So u r suggesting we should not
!
Regards,
David Handermann
On Thu, Jan 13, 2022 at 2:44 PM Joe Witt wrote:
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi 1.15.3.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org
through a proxy server.
Regards,
David Handermann
On Mon, Jan 17, 2022 at 10:07 AM Mark Bean wrote:
> Is anyone else having trouble building NiFi (main) on macOS? I recently
> upgraded to macOS Monterey 12.1 and since then I have not been able to
> build NiFi. I'm not sure if the f
,
David Handermann
On Tue, Jan 25, 2022 at 2:42 AM Isha Lamboo
wrote:
> Hi all,
>
> I hope this question is appropriate for the developers list, if not, I’ll
> move it to users.
>
> I have an Ansible role for NiFi that includes generating the NiFi
> properties files from templa
+1 binding
- Ran build using Node 16.13.2
- Verified hashes and signatures
- Verified License and Notice files
Thanks Scott!
Regards,
David Handermann
On Wed, Jan 26, 2022 at 8:17 AM Shane Ardell
wrote:
> +1 (non-binding).
>
> Performed all verification steps listed in the helper
arily a configuration problem, and changing the trust store has a
significant impact on the security profile of the system, this particular
scenario does not seem like a significant concern.
Regards,
David Handermann
On Wed, Mar 9, 2022 at 9:55 AM Joe Witt wrote:
> Mark
>
> The single u
Hi Steven,
Thanks for your interest! This would also be a great opportunity to
streamline the HTML generation approach to use something like Hugo or
similar static-site generation system.
Regards,
David Handermann
On Wed, Mar 9, 2022 at 12:44 PM Joe Witt wrote:
> Steven
>
> To sa
-1 (binding)
In light of a problem just reported with AccessToken.isExpired()
determination in the StandardOauth2TokenProvider service, this issue should
be corrected:
https://issues.apache.org/jira/browse/NIFI-9801
Regards,
David Handermann
On Wed, Mar 16, 2022 at 12:05 PM Mark Payne wrote
Apache NiFi community,
On behalf of the Apache NiFi PMC, I am very pleased to announce that Paul
Grey
has accepted the PMC's invitation to become a committer on the Apache NiFi
project.
Paul has contributed a number of pull requests and code reviews over the
past year, improving project security
Paul Grey for his efforts to improve the reliability
of the NiFi system tests on GitHub. The resource-constrained GitHub
runners can expose test stability problems that are difficult to track
down, but thanks to Paul's work, the stability of the system tests on
GitHub has improved.
Regards,
1 - 100 of 379 matches
Mail list logo