[jira] [Commented] (NIFI-13079) Is there a roadmap for bundle persistence provider?
[ https://issues.apache.org/jira/browse/NIFI-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839763#comment-17839763 ] Pierre Villard commented on NIFI-13079: --- I think it's better to discuss this in the Slack channels or via the email thread. The short answer is that it is absolutely used. I'm actually in the process of adding a lot of things so that it's better represented in the NiFi Registry. There are currently two persistence providers (local file system and S3), I filed a PR a long time ago to support GCS but never got merged, I may refresh that PR since I'm spending time on those topics lately. > Is there a roadmap for bundle persistence provider? > --- > > Key: NIFI-13079 > URL: https://issues.apache.org/jira/browse/NIFI-13079 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Igor Milavec >Priority: Minor > > Hi! > Based on the admin and user guides, it feels to me that the current status of > bundle persistence providers is in limbo? > The functionality is there, but it is not clear how to use it. I have found > documentation about how to configure NiFi Registry and how to upload a bundle > (using curl). I'm left wondering how this affects deployment, what are the > triggers for deployment, does it support SemVer, ... > Also, I could find no future plans for this feature. Is this being used at > all and are there plans to develop/support it in the future? > > Thank you! Igor -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13077) On-demand Extension Provider
Pierre Villard created NIFI-13077:
-
Summary: On-demand Extension Provider
Key: NIFI-13077
URL: https://issues.apache.org/jira/browse/NIFI-13077
Project: Apache NiFi
Issue Type: Epic
Components: Core Framework
Reporter: Pierre Villard
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the Kafka Connect NiFi plugin with the class
ExtensionClientDefinition. By adopting this approach in NiFi, it’d be much
easier to ship a much smaller version of NiFi and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13077) On-demand Extension Provider
[
https://issues.apache.org/jira/browse/NIFI-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13077:
--
Description:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the Kafka Connect NiFi plugin with the class
ExtensionClientDefinition. By adopting this approach in NiFi, it’d be much
easier to ship a much smaller version of NiFi and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
was:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded
[jira] [Updated] (NIFI-12858) Processor change history on property hover
[ https://issues.apache.org/jira/browse/NIFI-12858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12858: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Processor change history on property hover > -- > > Key: NIFI-12858 > URL: https://issues.apache.org/jira/browse/NIFI-12858 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 2.0.0-M1, 1.24.0, 1.25.0, 2.0.0-M2 >Reporter: Chris Conklin >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Attachments: nifi1.23.2.png, nifi1.24.png > > Time Spent: 20m > Remaining Estimate: 0h > > The history details list on processors changed order after release 1.23.2. > Previous sort on history upon hovering over some property was latest update > first. > Starting with release 1.24 this order changed to oldest change first. > Since only 5 history lines appear this makes the feature not very useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13070) Upgrade Netty to 4.1.109
[ https://issues.apache.org/jira/browse/NIFI-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13070: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Netty to 4.1.109 > > > Key: NIFI-13070 > URL: https://issues.apache.org/jira/browse/NIFI-13070 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Netty dependencies should be upgraded to > [4.1.109|https://netty.io/news/2024/04/15/4-1-109-Final.html] to incorporate > several bug fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13067) Upgrade Spring Security to 6.2.4
[ https://issues.apache.org/jira/browse/NIFI-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13067: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Security to 6.2.4 > > > Key: NIFI-13067 > URL: https://issues.apache.org/jira/browse/NIFI-13067 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 10m > Remaining Estimate: 0h > > Spring Security dependencies should be upgraded to > [6.2.4|https://github.com/spring-projects/spring-security/releases/tag/6.2.4] > to incorporate several minor bug fixes and transitive dependency upgrades. As > part of the upgrade, OpenSAML dependencies should be upgraded to 4.3.1 and > AspectJ should be upgraded to 1.9.22. > Spring Boot for Registry can also be incremented to > [3.2.5|https://github.com/spring-projects/spring-boot/releases/tag/v3.2.5] to > align with Spring Security 6.2.4 and Spring Framework 6.1.6. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13066) Upgrade Bouncy Castle to 1.78.1
[ https://issues.apache.org/jira/browse/NIFI-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13066: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Bouncy Castle to 1.78.1 > --- > > Key: NIFI-13066 > URL: https://issues.apache.org/jira/browse/NIFI-13066 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Bouncy Castle libraries should be upgraded to version > [1.78.1|https://www.bouncycastle.org/releasenotes.html#r1rv78] to incorporate > several bug fixes, which include resolving several vulnerabilities that apply > to usage patterns outside of NiFi integration points. > Bouncy Castle 1.78.1 corrects a dependency relationship issue with bcpg and > bcutil that caused issues with OpenPGP usage in version 1.78. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13052) CRON Driven components should be searchable
[ https://issues.apache.org/jira/browse/NIFI-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13052: -- Fix Version/s: 1.26.0 > CRON Driven components should be searchable > --- > > Key: NIFI-13052 > URL: https://issues.apache.org/jira/browse/NIFI-13052 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > By entering the keyword "timer" in the Search Bar, you can locate all > components with "Scheduling Strategy: Timer driven". > We should also be able to locate all components that have "Scheduling > Strategy: CRON driven". > This feature is documented in the User Guide under the "Search Components in > DataFlow" section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13052) CRON Driven components should be searchable
[ https://issues.apache.org/jira/browse/NIFI-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13052: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > CRON Driven components should be searchable > --- > > Key: NIFI-13052 > URL: https://issues.apache.org/jira/browse/NIFI-13052 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Fix For: 2.0.0-M3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > By entering the keyword "timer" in the Search Bar, you can locate all > components with "Scheduling Strategy: Timer driven". > We should also be able to locate all components that have "Scheduling > Strategy: CRON driven". > This feature is documented in the User Guide under the "Search Components in > DataFlow" section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13050) Add bundle dependencies info in NiFi Registry
[
https://issues.apache.org/jira/browse/NIFI-13050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13050:
--
Status: Patch Available (was: Open)
> Add bundle dependencies info in NiFi Registry
> -
>
> Key: NIFI-13050
> URL: https://issues.apache.org/jira/browse/NIFI-13050
> Project: Apache NiFi
> Issue Type: Improvement
> Components: NiFi Registry
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
>
> Follow-up improvement after NIFI-13048
> It'd be useful to display the dependencies for the bundles in NiFi Registry.
> The API endpoint is already exposed:
> {code:java}
> .../nifi-registry-api/bundles//versions/{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13050) Add bundle dependencies info in NiFi Registry
Pierre Villard created NIFI-13050:
-
Summary: Add bundle dependencies info in NiFi Registry
Key: NIFI-13050
URL: https://issues.apache.org/jira/browse/NIFI-13050
Project: Apache NiFi
Issue Type: Improvement
Components: NiFi Registry
Reporter: Pierre Villard
Assignee: Pierre Villard
Follow-up improvement after NIFI-13048
It'd be useful to display the dependencies for the bundles in NiFi Registry.
The API endpoint is already exposed:
{code:java}
.../nifi-registry-api/bundles//versions/{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13048) Add bundle build info in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13048: -- Status: Patch Available (was: Open) > Add bundle build info in NiFi Registry > -- > > Key: NIFI-13048 > URL: https://issues.apache.org/jira/browse/NIFI-13048 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When dealing with bundles, we should display the build info as well as the > size of the bundle and the NiFi API version that has been used to build it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13048) Add bundle build info in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13048: -- Description: When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build it. (was: When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build the it.) > Add bundle build info in NiFi Registry > -- > > Key: NIFI-13048 > URL: https://issues.apache.org/jira/browse/NIFI-13048 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > When dealing with bundles, we should display the build info as well as the > size of the bundle and the NiFi API version that has been used to build it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13048) Add bundle build info in NiFi Registry
Pierre Villard created NIFI-13048: - Summary: Add bundle build info in NiFi Registry Key: NIFI-13048 URL: https://issues.apache.org/jira/browse/NIFI-13048 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: Pierre Villard Assignee: Pierre Villard When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build the it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13046) Upgrade Solr dependencies to 8.11.3
[ https://issues.apache.org/jira/browse/NIFI-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13046. --- Fix Version/s: 1.26.0 Resolution: Fixed > Upgrade Solr dependencies to 8.11.3 > --- > > Key: NIFI-13046 > URL: https://issues.apache.org/jira/browse/NIFI-13046 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade Solr dependencies to 8.11.3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13038) Upgrade Groovy to 4.0.21
[ https://issues.apache.org/jira/browse/NIFI-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13038: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Groovy to 4.0.21 > > > Key: NIFI-13038 > URL: https://issues.apache.org/jira/browse/NIFI-13038 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Groovy dependencies should be upgraded to > [4.0.21|http://groovy-lang.org/changelogs/changelog-4.0.21.html] to > incorporate several transitive dependency upgrades. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13037) Upgrade Spring Framework to 5.3.34 on Support Branch
[ https://issues.apache.org/jira/browse/NIFI-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13037: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Framework to 5.3.34 on Support Branch > > > Key: NIFI-13037 > URL: https://issues.apache.org/jira/browse/NIFI-13037 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, MiNiFi, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Spring Framework dependencies on the support branch should be upgraded to > version > [5.3.34|https://github.com/spring-projects/spring-framework/releases/tag/v5.3.34] > to resolve several flagged vulnerabilities. Spring Security should be > upgraded to 5.8.11 and Jetty should be upgraded to > [9.4.54|https://github.com/jetty/jetty.project/releases/tag/jetty-9.4.54.v20240208] > to resolve CVE-2024-22201 related to HTTP/2 connection closing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13040) Upgrade Commons IO to 2.16.1
[ https://issues.apache.org/jira/browse/NIFI-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13040: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons IO to 2.16.1 > > > Key: NIFI-13040 > URL: https://issues.apache.org/jira/browse/NIFI-13040 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Commons IO should be upgraded to > [2.16.1|https://commons.apache.org/proper/commons-io/changes-report.html#a2.16.1] > to incorporate a number of bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13036) Upgrade Logback to 1.5.5 and SLF4J to 2.0.13
[
https://issues.apache.org/jira/browse/NIFI-13036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-13036.
---
Resolution: Fixed
> Upgrade Logback to 1.5.5 and SLF4J to 2.0.13
>
>
> Key: NIFI-13036
> URL: https://issues.apache.org/jira/browse/NIFI-13036
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Logback dependencies should be upgraded to
> [1.5.5|https://logback.qos.ch/news.html#1.5.5] and SLF4J should be upgraded
> to [2.0.13|https://www.slf4j.org/news.html#2.0.13] to incorporate several
> minor improvements.
> The Logback 1.5 release series requires Java 11, so it applies only to the
> main branch of Apache NiFi and cannot be backported to the support branch.
> Logback 1.5 decouples the core implementation from the {{logback-access}}
> module, which NiFi does not use, and is otherwise compatible with Logback 1.4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13033) Upgrade Jetty to 12.0.8
[ https://issues.apache.org/jira/browse/NIFI-13033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13033: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jetty to 12.0.8 > --- > > Key: NIFI-13033 > URL: https://issues.apache.org/jira/browse/NIFI-13033 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Jetty dependencies should be upgraded to > [12.0.8|https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.8] to > incorporate various bug fixes and feature improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13032) Upgrade Spring Framework to 6.1.6
[
https://issues.apache.org/jira/browse/NIFI-13032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13032:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade Spring Framework to 6.1.6
> -
>
> Key: NIFI-13032
> URL: https://issues.apache.org/jira/browse/NIFI-13032
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Spring Framework dependencies should be upgraded to
> [6.1.6|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.6]
> to incorporate several bug fixes and improvements. Bug fixes include a
> resolution for CVE-2024-22262, which relates to parsing URLs using the Spring
> {{UriComponentsBuilder}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13026) Add a read only mode to non secured NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13026: -- Resolution: Won't Do Status: Resolved (was: Patch Available) > Add a read only mode to non secured NiFi Registry > - > > Key: NIFI-13026 > URL: https://issues.apache.org/jira/browse/NIFI-13026 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > Time Spent: 50m > Remaining Estimate: 0h > > There are scenarios where NiFi Registry may be deployed in a non secured way. > When doing so, as of now, all users access would be anonymous and all > permissions would be granted. This improvement is to allow for a read-only > mode when NiFi Registry is not secured so that all users can access NiFi > Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13027) Warn users for small files processing in PutIceberg
[ https://issues.apache.org/jira/browse/NIFI-13027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13027: -- Status: Patch Available (was: Open) > Warn users for small files processing in PutIceberg > --- > > Key: NIFI-13027 > URL: https://issues.apache.org/jira/browse/NIFI-13027 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > While it can be a valid use case, it is a very bad idea to send a lot of > small flow files via the PutIceberg processor as it will generate a massive > amount of snapshot files. The recommendation is clearly to use a > MergeContent/MergeRecord processor before the PutIceberg processor to make > sure we limit the amount of individual files being sent to an Iceberg table. > While we can't force a user (this could be a flow analysis rule though) we > should let them know very clearly that what they're doing is likely a bad > idea and let them know what is the recommended way. However if the user is > sure they know what they're doing, they should be able to disable the warning. > This Jira is about adding: > * a property "Warn for small flow files" set to true by default > * a property "Minimum recommended file size" set to 10MB (depending on the > previous property, if set to true) > And if the warning is enabled and a processed flow file is below the limit, > then log a warning with the recommendation of using a Merge processor so that > a bulletin is generated and shown to the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13027) Warn users for small files processing in PutIceberg
Pierre Villard created NIFI-13027: - Summary: Warn users for small files processing in PutIceberg Key: NIFI-13027 URL: https://issues.apache.org/jira/browse/NIFI-13027 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard While it can be a valid use case, it is a very bad idea to send a lot of small flow files via the PutIceberg processor as it will generate a massive amount of snapshot files. The recommendation is clearly to use a MergeContent/MergeRecord processor before the PutIceberg processor to make sure we limit the amount of individual files being sent to an Iceberg table. While we can't force a user (this could be a flow analysis rule though) we should let them know very clearly that what they're doing is likely a bad idea and let them know what is the recommended way. However if the user is sure they know what they're doing, they should be able to disable the warning. This Jira is about adding: * a property "Warn for small flow files" set to true by default * a property "Minimum recommended file size" set to 10MB (depending on the previous property, if set to true) And if the warning is enabled and a processed flow file is below the limit, then log a warning with the recommendation of using a Merge processor so that a bulletin is generated and shown to the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13026) Add a read only mode to non secured NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13026: -- Status: Patch Available (was: Open) > Add a read only mode to non secured NiFi Registry > - > > Key: NIFI-13026 > URL: https://issues.apache.org/jira/browse/NIFI-13026 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > There are scenarios where NiFi Registry may be deployed in a non secured way. > When doing so, as of now, all users access would be anonymous and all > permissions would be granted. This improvement is to allow for a read-only > mode when NiFi Registry is not secured so that all users can access NiFi > Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13026) Add a read only mode to non secured NiFi Registry
Pierre Villard created NIFI-13026: - Summary: Add a read only mode to non secured NiFi Registry Key: NIFI-13026 URL: https://issues.apache.org/jira/browse/NIFI-13026 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: Pierre Villard Assignee: Pierre Villard There are scenarios where NiFi Registry may be deployed in a non secured way. When doing so, as of now, all users access would be anonymous and all permissions would be granted. This improvement is to allow for a read-only mode when NiFi Registry is not secured so that all users can access NiFi Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13025) NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service
[ https://issues.apache.org/jira/browse/NIFI-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13025: -- Status: Patch Available (was: Open) > NifiRegistryFlowRegistryClient to allow for truststore only SSL Context > Service > --- > > Key: NIFI-13025 > URL: https://issues.apache.org/jira/browse/NIFI-13025 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Right now the NifiRegistryFlowRegistryClient Registry Client, when configured > with an SSL Context Service, requires the SSL CS to be configured with both a > keystore and a truststore. However, there are valid deployment scenarios > where only a truststore should be configured in case anonymous access to the > Registry is desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13025) NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service
Pierre Villard created NIFI-13025: - Summary: NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service Key: NIFI-13025 URL: https://issues.apache.org/jira/browse/NIFI-13025 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Right now the NifiRegistryFlowRegistryClient Registry Client, when configured with an SSL Context Service, requires the SSL CS to be configured with both a keystore and a truststore. However, there are valid deployment scenarios where only a truststore should be configured in case anonymous access to the Registry is desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12889) Retry Kerberos Login on auth failures in HDFS processors
[ https://issues.apache.org/jira/browse/NIFI-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12889: -- Fix Version/s: 1.26.0 > Retry Kerberos Login on auth failures in HDFS processors > > > Key: NIFI-12889 > URL: https://issues.apache.org/jira/browse/NIFI-12889 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 4h > Remaining Estimate: 0h > > Currently if a Kerberos authentication failure happens (during ticket > relogin, e.g.) in the HDFS processors, the controller service must be > restarted manually in order for the processors to execute correctly. From the > processors we should reset the HDFS resources on auth failure to simulate a > "restart" of the controller service so relogin can occur correctly. > At a minimum this includes the following processors: > FetchHDFS > GetHDFS > GetHDFSFileInfo > PutHDFS > ListHDFS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13010) UpdateDatabaseTable Processor cannot use DBCPConnectionPoolLookup
[ https://issues.apache.org/jira/browse/NIFI-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13010. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > UpdateDatabaseTable Processor cannot use DBCPConnectionPoolLookup > - > > Key: NIFI-13010 > URL: https://issues.apache.org/jira/browse/NIFI-13010 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.25.0, 2.0.0-M2 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Minor > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The UpdateDatabaseTable processor fails to execute when it is configured to > use a DBCP Connection Pool Lookup. The flow file has database.name attribute, > However, when the processor runs, it gets the following error: > org.apache.nifi.processor.exception.ProcessException: > java.lang.UnsupportedOperationException: Cannot lookup DBCPConnectionPool > without attributes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10977) Add Documentation for Kubernetes Cluster Deployments
[ https://issues.apache.org/jira/browse/NIFI-10977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-10977: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Documentation for Kubernetes Cluster Deployments > > > Key: NIFI-10977 > URL: https://issues.apache.org/jira/browse/NIFI-10977 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 40m > Remaining Estimate: 0h > > Project documentation should be expanded to describe the basic features and > implementation of Kubernetes Leader Election and State Management. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12837) Add DFS setting to smb processors
[
https://issues.apache.org/jira/browse/NIFI-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12837:
--
Fix Version/s: 1.26.0
> Add DFS setting to smb processors
> -
>
> Key: NIFI-12837
> URL: https://issues.apache.org/jira/browse/NIFI-12837
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.25.0, 2.0.0-M2
>Reporter: Anders
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 2.0.0-M3, 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The hierynomus/smbj library has a setting for enabling DFS which is disabled
> by default:
> https://github.com/hierynomus/smbj/blob/f25d5c5478a5b73e9ba4202dcfb365974e15367e/src/main/java/com/hierynomus/smbj/SmbConfig.java#L106C17-L106C39
> This appears to cause problems in some SMB configurations.
> Patched
> https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> to test in my environment with:
> {code}
> $ git diff
> nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> diff --git
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
>
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> index 0895abfae0..eac765 100644
> ---
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> +++
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> @@ -46,6 +46,8 @@ public final class SmbUtils {
> }
> }
> +configBuilder.withDfsEnabled(true);
> +
> if (context.getProperty(USE_ENCRYPTION).isSet()) {
>
> configBuilder.withEncryptData(context.getProperty(USE_ENCRYPTION).asBoolean());
> }
> {code}
> This appeared to resolve the issue.
> It would be very useful if this setting was available to toggle in the UI for
> all SMB processors.
> Without this setting, I get a *STATUS_PATH_NOT_COVERED* error.
> Somewhat related hierynomus/smbj github issues:
> https://github.com/hierynomus/smbj/issues/152
> https://github.com/hierynomus/smbj/issues/419
> This setting should be made available in the following processors and
> services:
> * GetSmbFile
> * PutSmbFile
> * SmbjClientProviderService
> Edit: It might require some more changes to handle the connections and
> sessions correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12837) Add DFS setting to smb processors
[
https://issues.apache.org/jira/browse/NIFI-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12837:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add DFS setting to smb processors
> -
>
> Key: NIFI-12837
> URL: https://issues.apache.org/jira/browse/NIFI-12837
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.25.0, 2.0.0-M2
>Reporter: Anders
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The hierynomus/smbj library has a setting for enabling DFS which is disabled
> by default:
> https://github.com/hierynomus/smbj/blob/f25d5c5478a5b73e9ba4202dcfb365974e15367e/src/main/java/com/hierynomus/smbj/SmbConfig.java#L106C17-L106C39
> This appears to cause problems in some SMB configurations.
> Patched
> https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> to test in my environment with:
> {code}
> $ git diff
> nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> diff --git
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
>
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> index 0895abfae0..eac765 100644
> ---
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> +++
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> @@ -46,6 +46,8 @@ public final class SmbUtils {
> }
> }
> +configBuilder.withDfsEnabled(true);
> +
> if (context.getProperty(USE_ENCRYPTION).isSet()) {
>
> configBuilder.withEncryptData(context.getProperty(USE_ENCRYPTION).asBoolean());
> }
> {code}
> This appeared to resolve the issue.
> It would be very useful if this setting was available to toggle in the UI for
> all SMB processors.
> Without this setting, I get a *STATUS_PATH_NOT_COVERED* error.
> Somewhat related hierynomus/smbj github issues:
> https://github.com/hierynomus/smbj/issues/152
> https://github.com/hierynomus/smbj/issues/419
> This setting should be made available in the following processors and
> services:
> * GetSmbFile
> * PutSmbFile
> * SmbjClientProviderService
> Edit: It might require some more changes to handle the connections and
> sessions correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12889) Retry Kerberos Login on auth failures in HDFS processors
[ https://issues.apache.org/jira/browse/NIFI-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12889: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) Marked as fixed for 2.0-M3 but we also want a backport into 1.x > Retry Kerberos Login on auth failures in HDFS processors > > > Key: NIFI-12889 > URL: https://issues.apache.org/jira/browse/NIFI-12889 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Currently if a Kerberos authentication failure happens (during ticket > relogin, e.g.) in the HDFS processors, the controller service must be > restarted manually in order for the processors to execute correctly. From the > processors we should reset the HDFS resources on auth failure to simulate a > "restart" of the controller service so relogin can occur correctly. > At a minimum this includes the following processors: > FetchHDFS > GetHDFS > GetHDFSFileInfo > PutHDFS > ListHDFS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
[ https://issues.apache.org/jira/browse/NIFI-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13008: -- Status: Patch Available (was: In Progress) > CLI command to upgrade all instances of a versioned flow > > > Key: NIFI-13008 > URL: https://issues.apache.org/jira/browse/NIFI-13008 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Add a CLI command allowing someone to upgrade all the instances of a given > versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
[ https://issues.apache.org/jira/browse/NIFI-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13008: -- Labels: backport-needed (was: ) > CLI command to upgrade all instances of a versioned flow > > > Key: NIFI-13008 > URL: https://issues.apache.org/jira/browse/NIFI-13008 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Add a CLI command allowing someone to upgrade all the instances of a given > versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
Pierre Villard created NIFI-13008: - Summary: CLI command to upgrade all instances of a versioned flow Key: NIFI-13008 URL: https://issues.apache.org/jira/browse/NIFI-13008 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Pierre Villard Assignee: Pierre Villard Add a CLI command allowing someone to upgrade all the instances of a given versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12994) Fix NPE when requesting Flow Analysis Results for a Process Group
[ https://issues.apache.org/jira/browse/NIFI-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12994. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > Fix NPE when requesting Flow Analysis Results for a Process Group > - > > Key: NIFI-12994 > URL: https://issues.apache.org/jira/browse/NIFI-12994 > Project: Apache NiFi > Issue Type: Bug >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > When requesting Flow Analysis Results for a Process Group the underlying Rule > Violations are checked if registered for the same group id. That group id is > the group id of the violating component. However there can be components that > don't belong to a Process Group, in which case this group id is going to be > null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12987) Controller Service type should be searchable
[ https://issues.apache.org/jira/browse/NIFI-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12987: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Controller Service type should be searchable > > > Key: NIFI-12987 > URL: https://issues.apache.org/jira/browse/NIFI-12987 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.25.0 >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently controller service name, uuid, property name, property value and > comments are all searchable. However you cannot search by controller service > type (class name) like you can with other components. Allow the search to > find controller services by type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12988) Streamline Iceberg Test Utils Dependencies
[
https://issues.apache.org/jira/browse/NIFI-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12988:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Streamline Iceberg Test Utils Dependencies
> --
>
> Key: NIFI-12988
> URL: https://issues.apache.org/jira/browse/NIFI-12988
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Following the move of {{nifi-hive-test-utils}} to
> {{{}nifi-iceberg-test-utils{}}}, several of the dependencies and exclusions
> can be streamlined to reduce duplication and unnecessary references.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
[ https://issues.apache.org/jira/browse/NIFI-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12984: -- Status: Patch Available (was: Open) > Bump Snowflake Ingest SDK to 2.1.0 > -- > > Key: NIFI-12984 > URL: https://issues.apache.org/jira/browse/NIFI-12984 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the > release notes. See: > [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
[ https://issues.apache.org/jira/browse/NIFI-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12984: -- Labels: backport-needed (was: ) > Bump Snowflake Ingest SDK to 2.1.0 > -- > > Key: NIFI-12984 > URL: https://issues.apache.org/jira/browse/NIFI-12984 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the > release notes. See: > [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
Pierre Villard created NIFI-12984: - Summary: Bump Snowflake Ingest SDK to 2.1.0 Key: NIFI-12984 URL: https://issues.apache.org/jira/browse/NIFI-12984 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the release notes. See: [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12981) Remove Hive 3 Components
[ https://issues.apache.org/jira/browse/NIFI-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12981: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Remove Hive 3 Components > > > Key: NIFI-12981 > URL: https://issues.apache.org/jira/browse/NIFI-12981 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Following the release of Apache Hive 4.0.0, Apache NiFi components support > Hive 3 should be removed from the main branch. NiFi 2.0.0 Milestone 1 and > Milestone 2 bundles remain available in Maven Central. Future support for > Hive 4 can be considered separately. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12980) Deprecate Hive 3 Components for Removal
[ https://issues.apache.org/jira/browse/NIFI-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12980: -- Fix Version/s: 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Deprecate Hive 3 Components for Removal > --- > > Key: NIFI-12980 > URL: https://issues.apache.org/jira/browse/NIFI-12980 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Hive has released version 4.0.0 incorporating a number changes from > the previous version. Following the NiFI 2.0 Release Goals of removing > support for previous major versions of various components, Hive 3 Processors > should be deprecated on the support branch for subsequent removal from the > main branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12975) Limit number of POST on /subjects for Confluent Schema Registry
Pierre Villard created NIFI-12975:
-
Summary: Limit number of POST on /subjects for Confluent Schema
Registry
Key: NIFI-12975
URL: https://issues.apache.org/jira/browse/NIFI-12975
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Reporter: Pierre Villard
Right now, when retrieving a schema by ID, we first do
{code:java}
// GET /schemas/ids/{int: id}{code}
but that does not give us everything, so... we get the subjects associated
{code:java}
// GET /schemas/ids/{int: id}/subjects{code}
which is a list of -key or -value depending on what the schema is
associated with for the topic
Then, we recursively use the subjects calling
{code:java}
// POST /subjects/(string: subject){code}
until we get one 200 response. From this response we get all the information we
want.
While this is working, the problem is that NiFi may not be authorized to call
this API for some subjects. So depending on the order of the list of subjects,
we may be causing a lot of 403 errors on the Schema Registry side and its audit
logs.
When the reader is called from a Kafka processor, we may be able to pass the
topic name information that would give us a way to be smarter about which
subjects to call and avoid the 403 errors. That would not solve the problem in
all possible scenarios but that would likely help in most cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12969) Under heavy load, nifi node unable to rejoin cluster, graph modified with temp funnel
[
https://issues.apache.org/jira/browse/NIFI-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832247#comment-17832247
]
Pierre Villard commented on NIFI-12969:
---
That is interesting, I'll definitely be extremely interested in whatever you
find to solve this issue.
> Under heavy load, nifi node unable to rejoin cluster, graph modified with
> temp funnel
> -
>
> Key: NIFI-12969
> URL: https://issues.apache.org/jira/browse/NIFI-12969
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.24.0, 2.0.0-M2
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> Under heavy load, if a node leaves the cluster (due to heartbeat time out),
> many times it is unable to rejoin the cluster.
> The nodes' graph will have been modified with a temp-funnel as well.
> Appears to be some sort of [timing
> issue|https://github.com/apache/nifi/blob/rel/nifi-2.0.0-M2/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/connectable/StandardConnection.java#L298]
> # To reproduce, on a nifi cluster of three nodes, set up:
> 2 GenerateFlowFile processors -> PG
> Inside PG:
> inputPort -> UpdateAttribute
> # Keep all defaults except for the following:
> For UpdateAttribute terminate the success relationship
> One of the GenerateFlowFile processors can be disabled,
> the other one should have Run Schedule to be 0 min (this will allow for the
> heavy load)
> # In nifi.properties (on all 3 nodes) to allow for nodes to fall out of the
> cluster, set: nifi.cluster.protocol.heartbeat.interval=2 sec (default is 5)
> nifi.cluster.protocol.heartbeat.missable.max=1 (default is 8)
> Restart nifi. Start flow. The nodes will quickly fall out and rejoin cluster.
> After a few minutes one will likely not be able to rejoin. The graph for
> that node will have the disabled GenerateFlowFile now pointing to a funnel (a
> temp-funnel) instead of the PG
> Stack trace on that nodes nifi-app.log will look like this: (this is from
> 2.0.0-M2):
> {code:java}
> 2024-03-28 13:55:19,395 INFO [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Node disconnected due to Failed to
> properly handle Reconnection request due to org.apache.nifi.control
> ler.serialization.FlowSynchronizationException: Failed to connect node to
> cluster because local flow controller partially updated. Administrator should
> disconnect node and review flow for corrup
> tion.
> 2024-03-28 13:55:19,395 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.serialization.FlowSynchroniza
> tionException: Failed to connect node to cluster because local flow
> controller partially updated. Administrator should disconnect node and review
> flow for corruption.
> org.apache.nifi.controller.serialization.FlowSynchronizationException: Failed
> to connect node to cluster because local flow controller partially updated.
> Administrator should disconnect node and
> review flow for corruption.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:985)
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:655)
> at
> org.apache.nifi.controller.StandardFlowService$1.run(StandardFlowService.java:384)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by:
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Cannot change destination of Connection
> because FlowFiles from this Connection
> are currently held by LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b,
> type=INPUT_PORT, name=inputPort, group=innerPG]
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:472)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:223)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1740)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:805)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:954)
> ... 3 common frames omitted
> Caused by: java.lang.IllegalStateException: Cannot change destination of
> Connection because FlowFiles from this Connection are currently held by
> LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b
> ,
[jira] [Commented] (NIFI-12969) Under heavy load, nifi node unable to rejoin cluster, graph modified with temp funnel
[
https://issues.apache.org/jira/browse/NIFI-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832223#comment-17832223
]
Pierre Villard commented on NIFI-12969:
---
[~Nissim Shiman] - I think there may be good chances that this is solved with
NIFI-12232
> Under heavy load, nifi node unable to rejoin cluster, graph modified with
> temp funnel
> -
>
> Key: NIFI-12969
> URL: https://issues.apache.org/jira/browse/NIFI-12969
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.24.0, 2.0.0-M2
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> Under heavy load, if a node leaves the cluster (due to heartbeat time out),
> many times it is unable to rejoin the cluster.
> The nodes' graph will have been modified with a temp-funnel as well.
> Appears to be some sort of [timing
> issue|https://github.com/apache/nifi/blob/rel/nifi-2.0.0-M2/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/connectable/StandardConnection.java#L298]
> # To reproduce, on a nifi cluster of three nodes, set up:
> 2 GenerateFlowFile processors -> PG
> Inside PG:
> inputPort -> UpdateAttribute
> # Keep all defaults except for the following:
> For UpdateAttribute terminate the success relationship
> One of the GenerateFlowFile processors can be disabled,
> the other one should have Run Schedule to be 0 min (this will allow for the
> heavy load)
> # In nifi.properties (on all 3 nodes) to allow for nodes to fall out of the
> cluster, set: nifi.cluster.protocol.heartbeat.interval=2 sec (default is 5)
> nifi.cluster.protocol.heartbeat.missable.max=1 (default is 8)
> Restart nifi. Start flow. The nodes will quickly fall out and rejoin cluster.
> After a few minutes one will likely not be able to rejoin. The graph for
> that node will have the disabled GenerateFlowFile now pointing to a funnel (a
> temp-funnel) instead of the PG
> Stack trace on that nodes nifi-app.log will look like this: (this is from
> 2.0.0-M2):
> {code:java}
> 2024-03-28 13:55:19,395 INFO [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Node disconnected due to Failed to
> properly handle Reconnection request due to org.apache.nifi.control
> ler.serialization.FlowSynchronizationException: Failed to connect node to
> cluster because local flow controller partially updated. Administrator should
> disconnect node and review flow for corrup
> tion.
> 2024-03-28 13:55:19,395 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.serialization.FlowSynchroniza
> tionException: Failed to connect node to cluster because local flow
> controller partially updated. Administrator should disconnect node and review
> flow for corruption.
> org.apache.nifi.controller.serialization.FlowSynchronizationException: Failed
> to connect node to cluster because local flow controller partially updated.
> Administrator should disconnect node and
> review flow for corruption.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:985)
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:655)
> at
> org.apache.nifi.controller.StandardFlowService$1.run(StandardFlowService.java:384)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by:
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Cannot change destination of Connection
> because FlowFiles from this Connection
> are currently held by LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b,
> type=INPUT_PORT, name=inputPort, group=innerPG]
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:472)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:223)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1740)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:805)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:954)
> ... 3 common frames omitted
> Caused by: java.lang.IllegalStateException: Cannot change destination of
> Connection because FlowFiles from this Connection are currently held by
> LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b
> , type=INPUT_PORT,
[jira] [Created] (NIFI-12973) Add Process Group scope to Flow Analysis rules
Pierre Villard created NIFI-12973: - Summary: Add Process Group scope to Flow Analysis rules Key: NIFI-12973 URL: https://issues.apache.org/jira/browse/NIFI-12973 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard I think it'd be useful to have an optional property in all Flow Analysis rules to scope a rule execution to a specific process group (and its embedded process groups). Most NiFi users are using NiFi in a multi tenant way and are dedicating a process group to a given team. Different rules may apply across different teams hence the advantage of scoping a rule to a process group (when it makes sense for the rule). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12924) FlowAnalysis streamline
[ https://issues.apache.org/jira/browse/NIFI-12924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12924. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > FlowAnalysis streamline > --- > > Key: NIFI-12924 > URL: https://issues.apache.org/jira/browse/NIFI-12924 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Have flow analysis occur as needed instead of as demanded or regularly. When > the flow is modified occurs or there are changes among the rules a background > thread will run a flow analysis within 5 seconds. Otherwise no analysis > occurs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Status: Patch Available (was: Open) > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard reassigned NIFI-12972: - Assignee: Pierre Villard > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Description: Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. For reference, the related code is here: https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 was: Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12972) UI - Improve listing of relationships for a connection
Pierre Villard created NIFI-12972: - Summary: UI - Improve listing of relationships for a connection Key: NIFI-12972 URL: https://issues.apache.org/jira/browse/NIFI-12972 Project: Apache NiFi Issue Type: Improvement Components: Core UI Affects Versions: 2.0.0-M2, 1.25.0 Reporter: Pierre Villard Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Affects Version/s: (was: 1.25.0) (was: 2.0.0-M2) > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12966) Upgrade Netty to 4.1.108
[ https://issues.apache.org/jira/browse/NIFI-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12966: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Netty to 4.1.108 > > > Key: NIFI-12966 > URL: https://issues.apache.org/jira/browse/NIFI-12966 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Netty dependencies should be upgraded to > [4.1.108|https://netty.io/news/2024/03/21/4-1-108-Final.html] to incorporate > several improvements and a resolution for CVE-2024-29025 related to HTTP POST > request decoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12965) Upgrade Guava to 33.1.0
[ https://issues.apache.org/jira/browse/NIFI-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12965: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Guava to 33.1.0 > --- > > Key: NIFI-12965 > URL: https://issues.apache.org/jira/browse/NIFI-12965 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Google Guava dependencies should be upgraded to > [33.1.0|https://github.com/google/guava/releases/tag/v33.1.0] to incorporate > bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12945) Upgrade Commons Configuration and Guava Transitive Dependencies
[ https://issues.apache.org/jira/browse/NIFI-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12945: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons Configuration and Guava Transitive Dependencies > --- > > Key: NIFI-12945 > URL: https://issues.apache.org/jira/browse/NIFI-12945 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Recent upgrades to Apache Commons Configuration 2.10.1 and should be > propagated to transitive dependencies in several extension modules. The > extension modules with transitive dependencies include Hadoop and Hive > components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12955) Update Dependency Check Suppressions
[ https://issues.apache.org/jira/browse/NIFI-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12955: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Update Dependency Check Suppressions > > > Key: NIFI-12955 > URL: https://issues.apache.org/jira/browse/NIFI-12955 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > The OWASP Dependency Check suppressions configuration includes a number of > items that no longer apply based on library upgrades and improvements to the > scanner itself. Unused suppressions should be removed and others should be > added as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12957) Upgrade Azure SDK BOM to 1.2.21
[ https://issues.apache.org/jira/browse/NIFI-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12957: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Azure SDK BOM to 1.2.21 > --- > > Key: NIFI-12957 > URL: https://issues.apache.org/jira/browse/NIFI-12957 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Azure SDK BOM dependency should be upgraded to > [1.2.21|https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/boms/azure-sdk-bom/CHANGELOG.md] > to incorporate the latest set of Azure libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12962) Upgrade Spring Framework to 6.1.5
[ https://issues.apache.org/jira/browse/NIFI-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12962: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Framework to 6.1.5 > - > > Key: NIFI-12962 > URL: https://issues.apache.org/jira/browse/NIFI-12962 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Spring Framework dependencies should be upgraded to > [6.1.5|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.5] > to align both NiFi and NiFi Registry on the same version. > Spring 6.1.0 introduced changes in AspectJ annotation expression parsing, > resulting in test failures for Auditor classes. Enabling parameters during > Java compilation as described in [explicit argument > names|https://docs.spring.io/spring-framework/reference/core/aop/ataspectj/advice.html#aop-ataspectj-advice-params-names-explicit] > documentation for Spring Framework resolves expression parsing and allows > the AspectJ annotations to work without changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12888) OAuth2 token refresh doesn't work in Email processors
[ https://issues.apache.org/jira/browse/NIFI-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12888. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > OAuth2 token refresh doesn't work in Email processors > - > > Key: NIFI-12888 > URL: https://issues.apache.org/jira/browse/NIFI-12888 > Project: Apache NiFi > Issue Type: Bug >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h > Remaining Estimate: 0h > > ConsumeIMAP and ConsumePOP3 both inherit the AbstractEmailProcessor in which > the OAuth2 token refresh handling is not handled properly. > The object that is receiving the emails is created and finalized only once. > When the token expires, nothing makes to refresh logic to run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12954) Upgrade AWS BOM references
[ https://issues.apache.org/jira/browse/NIFI-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12954: -- Status: Patch Available (was: Open) > Upgrade AWS BOM references > -- > > Key: NIFI-12954 > URL: https://issues.apache.org/jira/browse/NIFI-12954 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Upgrade AWS BOM references > * 1.x from 1.12.637 to 1.12.686 > * 2.x from 2.23.3 to 2.25.16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12954) Upgrade AWS BOM references
Pierre Villard created NIFI-12954: - Summary: Upgrade AWS BOM references Key: NIFI-12954 URL: https://issues.apache.org/jira/browse/NIFI-12954 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Upgrade AWS BOM references * 1.x from 1.12.637 to 1.12.686 * 2.x from 2.23.3 to 2.25.16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12953) Upgrade AWS Kinesis client to 2.5.7
[ https://issues.apache.org/jira/browse/NIFI-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12953: -- Status: Patch Available (was: Open) > Upgrade AWS Kinesis client to 2.5.7 > --- > > Key: NIFI-12953 > URL: https://issues.apache.org/jira/browse/NIFI-12953 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade AWS Kinesis client to 2.5.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12953) Upgrade AWS Kinesis client to 2.5.7
Pierre Villard created NIFI-12953: - Summary: Upgrade AWS Kinesis client to 2.5.7 Key: NIFI-12953 URL: https://issues.apache.org/jira/browse/NIFI-12953 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Upgrade AWS Kinesis client to 2.5.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12949) Upgrade Box SDK to 4.8.0
[ https://issues.apache.org/jira/browse/NIFI-12949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12949: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Box SDK to 4.8.0 > > > Key: NIFI-12949 > URL: https://issues.apache.org/jira/browse/NIFI-12949 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Box Java SDK should be upgraded to > [4.8.0|https://github.com/box/box-java-sdk/releases/tag/v4.8.0] to > incorporate several transitive dependency upgrades, including more recent > Bouncy Castle dependency coordinates. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12947) Upgrade MIME4J to 0.8.11
[
https://issues.apache.org/jira/browse/NIFI-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12947:
--
Fix Version/s: 2.0.0-M3
1.26.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade MIME4J to 0.8.11
>
>
> Key: NIFI-12947
> URL: https://issues.apache.org/jira/browse/NIFI-12947
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Labels: backport-needed
> Fix For: 2.0.0-M3, 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Apache MIME4J should be upgraded to 0.8.11 to mitigate CVE-2024-21742 related
> to MIME message parsing. Apache MIME4J is a transitive dependency of the
> Apache Tika Parsers library used in the {{nifi-media-processors}} module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12936) ListGCSBucket should reset its tracking state after configuration change
[ https://issues.apache.org/jira/browse/NIFI-12936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12936: -- Fix Version/s: 1.26.0 > ListGCSBucket should reset its tracking state after configuration change > > > Key: NIFI-12936 > URL: https://issues.apache.org/jira/browse/NIFI-12936 > Project: Apache NiFi > Issue Type: Bug >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Same as NIFI-12732 but for ListGCSBucket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12944) Add attribute corresponding to peer address of SNMP TRAP PDUs
[ https://issues.apache.org/jira/browse/NIFI-12944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12944: -- Component/s: Extensions > Add attribute corresponding to peer address of SNMP TRAP PDUs > -- > > Key: NIFI-12944 > URL: https://issues.apache.org/jira/browse/NIFI-12944 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Ricardo Ferreira >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Add attribute corresponding to peer address of SNMP traps that are received. > This is useful to determine where a trap originated from, as not all SNMPv2 > traps include an OID that identifies the sender. > The information is placed in the attribute with name snmp$peerAddress -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12944) Add attribute corresponding to peer address of SNMP TRAP PDUs
[ https://issues.apache.org/jira/browse/NIFI-12944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12944. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > Add attribute corresponding to peer address of SNMP TRAP PDUs > -- > > Key: NIFI-12944 > URL: https://issues.apache.org/jira/browse/NIFI-12944 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Ricardo Ferreira >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add attribute corresponding to peer address of SNMP traps that are received. > This is useful to determine where a trap originated from, as not all SNMPv2 > traps include an OID that identifies the sender. > The information is placed in the attribute with name snmp$peerAddress -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12928) Add Simple Write strategy in PutAzureDataLakeStorage
[ https://issues.apache.org/jira/browse/NIFI-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12928: -- Fix Version/s: 1.26.0 > Add Simple Write strategy in PutAzureDataLakeStorage > > > Key: NIFI-12928 > URL: https://issues.apache.org/jira/browse/NIFI-12928 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Minor > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > NIFI-8248 introduced temporary location for file uploads in > PutAzureDataLakeStorage. The file is uploaded into a temporary directory > first and then moved to the final location. > The motivation behind this was that the file upload with Azure client API is > a 2-step process: first an empty file is created, then the content is > uploaded. The unfinished empty file would be available for listing / > fetching. Also, if the put processor is in 'replace' mode and the uploading > fails, then old content is lost as the file was already cleared. > However, this behaviour is not desired in all cases and writing the file > directly to its final location would be preferred. E.g. when ACL is used for > permission handling and the temporary folder would need extra administration > (and the files are not listed/read in parallel so there is no issue with the > partially written files). > Add 'Writing Strategy' property with 'Write and Rename' (current behaviour, > default) and 'Simple Write' options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12936) ListGCSBucket should reset its tracking state after configuration change
[ https://issues.apache.org/jira/browse/NIFI-12936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12936: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > ListGCSBucket should reset its tracking state after configuration change > > > Key: NIFI-12936 > URL: https://issues.apache.org/jira/browse/NIFI-12936 > Project: Apache NiFi > Issue Type: Bug >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Same as NIFI-12732 but for ListGCSBucket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12942) Upgrade Jetty to 12.0.7
[ https://issues.apache.org/jira/browse/NIFI-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12942: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jetty to 12.0.7 > --- > > Key: NIFI-12942 > URL: https://issues.apache.org/jira/browse/NIFI-12942 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Jetty dependencies should be upgraded to > [12.0.7|https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.7] on > the main branch to incorporate recent bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12928) Add Simple Write strategy in PutAzureDataLakeStorage
[ https://issues.apache.org/jira/browse/NIFI-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12928: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Simple Write strategy in PutAzureDataLakeStorage > > > Key: NIFI-12928 > URL: https://issues.apache.org/jira/browse/NIFI-12928 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Minor > Fix For: 2.0.0-M3 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > NIFI-8248 introduced temporary location for file uploads in > PutAzureDataLakeStorage. The file is uploaded into a temporary directory > first and then moved to the final location. > The motivation behind this was that the file upload with Azure client API is > a 2-step process: first an empty file is created, then the content is > uploaded. The unfinished empty file would be available for listing / > fetching. Also, if the put processor is in 'replace' mode and the uploading > fails, then old content is lost as the file was already cleared. > However, this behaviour is not desired in all cases and writing the file > directly to its final location would be preferred. E.g. when ACL is used for > permission handling and the temporary folder would need extra administration > (and the files are not listed/read in parallel so there is no issue with the > partially written files). > Add 'Writing Strategy' property with 'Write and Rename' (current behaviour, > default) and 'Simple Write' options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12929) Logout go to an infinite redirect loop behind knox
[ https://issues.apache.org/jira/browse/NIFI-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12929. --- Fix Version/s: 1.26.0 Resolution: Fixed > Logout go to an infinite redirect loop behind knox > -- > > Key: NIFI-12929 > URL: https://issues.apache.org/jira/browse/NIFI-12929 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.25.0, 1.26.0 >Reporter: Zoltán Kornél Török >Assignee: Zoltán Kornél Török >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When I tried to logout from nifi using a knox, 1.25 remained in an infinite > loop during logout. As turned out in case of 1.25 the LogoutFilter not do an > actual redirect to logout/complete which cause some issues with knox. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12933) Rearrange properties on GCP processors
[
https://issues.apache.org/jira/browse/NIFI-12933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12933:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Rearrange properties on GCP processors
> --
>
> Key: NIFI-12933
> URL: https://issues.apache.org/jira/browse/NIFI-12933
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Parent classes of the GCP processors define some common properties and they
> are added to the processors via
> {{{}descriptors.addAll(super.getSupportedPropertyDescriptors()){}}}.
> This practice leads to weird property ordering in most cases and it is not
> worth using it. E.g. "Number of retries" precedes "Bucket" and "Key"
> properties in PutGCSObject.
> Get rid of {{super.getSupportedPropertyDescriptors()}} and reorder the
> properties in a more reasonable way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12895) GetSmbFile and PutSmbFile has forced 5 sec timeout
[
https://issues.apache.org/jira/browse/NIFI-12895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12895:
--
Fix Version/s: 2.0.0-M3
1.26.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> GetSmbFile and PutSmbFile has forced 5 sec timeout
> --
>
> Key: NIFI-12895
> URL: https://issues.apache.org/jira/browse/NIFI-12895
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.25.0, 2.0.0-M2
>Reporter: Anders
>Assignee: Peter Turcsanyi
>Priority: Minor
> Fix For: 2.0.0-M3, 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It seems like timeout was introduced with the SmbjClientProviderService, and
> SmbUtils.java defines the withTimeout setting from the underlying smbj
> library.
> In SmbProperties.java, the default timeout value is set to 5 sec and you can
> configure it in the SmbjClientProviderService.
> However, the older GetSmbFile and PutSmbFile processors uses SmbUtils.java as
> well, but the timeout configuration item is not exposed in their config ui.
> The timeout setting should be added to the UI for GetSmbFile and PutSmbFile.
> I think it's enough to add the following lines to PutSmbFile.java and
> GetSmbFile.java:
> {code}
> ...
> import static org.apache.nifi.smb.common.SmbProperties.TIMEOUT;
> ...
> descriptors.add(TIMEOUT);
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-12938) Upgrade Iceberg from 1.4.3 to 1.5.0
[ https://issues.apache.org/jira/browse/NIFI-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12938. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > Upgrade Iceberg from 1.4.3 to 1.5.0 > --- > > Key: NIFI-12938 > URL: https://issues.apache.org/jira/browse/NIFI-12938 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Iceberg [1.5.0|https://iceberg.apache.org/releases/#150-release] adds > a variety of new features and bug fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12782) Migrate GCS processors' Proxy properties to ProxyConfigurationService
[ https://issues.apache.org/jira/browse/NIFI-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12782: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Migrate GCS processors' Proxy properties to ProxyConfigurationService > - > > Key: NIFI-12782 > URL: https://issues.apache.org/jira/browse/NIFI-12782 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Peter Turcsanyi >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Get rid of the obsolete processor level Proxy properties in all GCS > processors and add migration code to convert them to > ProxyConfigurationService. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12503) Missing Documentation for nifi-api
[ https://issues.apache.org/jira/browse/NIFI-12503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12503. --- Fix Version/s: 1.26.0 Resolution: Fixed > Missing Documentation for nifi-api > -- > > Key: NIFI-12503 > URL: https://issues.apache.org/jira/browse/NIFI-12503 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.25.0 >Reporter: Steven Matison >Assignee: endzeit >Priority: Minor > Fix For: 1.26.0 > > Attachments: SAMSAL_0-1701894321710.png > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Community user has noticed that nifi-api docs are missing required request > values. One such example is groupName on the api call for uploading > process-groups: > /process-groups/upload > > > More dialouge and original conversation here: > [https://community.cloudera.com/t5/Support-Questions/NIFI-API-REST-Upload-Json-definition-flow-file/m-p/380384#M244057] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12920) Remove Cassandra 3 Components
[ https://issues.apache.org/jira/browse/NIFI-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12920: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Remove Cassandra 3 Components > - > > Key: NIFI-12920 > URL: https://issues.apache.org/jira/browse/NIFI-12920 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Based on the [mailing list discussion > thread|https://lists.apache.org/thread/gx8nsrqrfxd4m3s0mj0145dhhhswq2m9] on > regarding new Cassandra component support, the existing nifi-cassandra-bundle > and associated components should be removed from the main branch for NiFi > version 2. > Removing existing components will provide the opportunity for a new > implementation based on current driver versions. > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12919) Deprecate Cassandra 3 Components for Removal
[ https://issues.apache.org/jira/browse/NIFI-12919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12919: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Deprecate Cassandra 3 Components for Removal > > > Key: NIFI-12919 > URL: https://issues.apache.org/jira/browse/NIFI-12919 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The current nifi-cassandra-bundle contains several Controller Services and > Processors based on the Datastax 3 driver. These components do not provide > sufficient abstraction from the Datastax 3 driver, which is has been > obsoleted by newer driver versions. > Following a [mailing list discussion > thread|https://lists.apache.org/thread/gx8nsrqrfxd4m3s0mj0145dhhhswq2m9] on > next steps, the nifi-cassandra-bundle and associated components should be > deprecated on the support branch for the NiFi version 1 release line and > removed from the main branch for NiFi version 2. This approach will provide > the opportunity for a new implementation based on current driver versions > without implying direct compatibility and associated problems with the legacy > driver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12897) Allow users to upload files/resources to nifi for use in the dataflow
[ https://issues.apache.org/jira/browse/NIFI-12897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828068#comment-17828068 ] Pierre Villard commented on NIFI-12897: --- Thanks Mark! Do you prefer to have a discussion here or via the comments of the feature proposal? > Allow users to upload files/resources to nifi for use in the dataflow > - > > Key: NIFI-12897 > URL: https://issues.apache.org/jira/browse/NIFI-12897 > Project: Apache NiFi > Issue Type: Epic > Components: Core Framework, Core UI >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > > A common feature request that we receive is to make it easier to upload a > resource file, such as JDBC Driver JAR to nifi so that all of the nodes > receive the file. This epic is meant to capture that request -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12909) Upgrade Nimbus JOSE+JWT
[ https://issues.apache.org/jira/browse/NIFI-12909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12909: -- Labels: backport-needed (was: ) > Upgrade Nimbus JOSE+JWT > --- > > Key: NIFI-12909 > URL: https://issues.apache.org/jira/browse/NIFI-12909 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade Nimbus JOSE+JWT to 9.37.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12909) Upgrade Nimbus JOSE+JWT
[ https://issues.apache.org/jira/browse/NIFI-12909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12909: -- Status: Patch Available (was: In Progress) > Upgrade Nimbus JOSE+JWT > --- > > Key: NIFI-12909 > URL: https://issues.apache.org/jira/browse/NIFI-12909 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade Nimbus JOSE+JWT to 9.37.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12909) Upgrade Nimbus JOSE+JWT
Pierre Villard created NIFI-12909: - Summary: Upgrade Nimbus JOSE+JWT Key: NIFI-12909 URL: https://issues.apache.org/jira/browse/NIFI-12909 Project: Apache NiFi Issue Type: Improvement Components: Core Framework, Extensions Reporter: Pierre Villard Assignee: Pierre Villard Upgrade Nimbus JOSE+JWT to 9.37.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12862) FlowAnalysisResults should not leak anauthorized component details
[ https://issues.apache.org/jira/browse/NIFI-12862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12862. --- Fix Version/s: 2.0.0 Resolution: Fixed > FlowAnalysisResults should not leak anauthorized component details > -- > > Key: NIFI-12862 > URL: https://issues.apache.org/jira/browse/NIFI-12862 > Project: Apache NiFi > Issue Type: Bug >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The FlowAnalysisResultEntity hold FlowAnalysisRuleViolationDTO that contain > the name of a violating component as a message describing the violation. This > usually contains details about the violating component. > A user can see these even if they don't have read permission for that > particular component. > In clustered environment the request merger filters out such violations but > in a non-clustered environment there is no such filtering phase. > The FlowAnalysisRuleViolationDTO itself should be built accordingly and leave > certain details blank when the user lacks read permissions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10707) Add Proxy Configuration Service to new PutBigQuery processor
[ https://issues.apache.org/jira/browse/NIFI-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-10707: -- Fix Version/s: 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Proxy Configuration Service to new PutBigQuery processor > > > Key: NIFI-10707 > URL: https://issues.apache.org/jira/browse/NIFI-10707 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Csaba Bejan >Assignee: Peter Turcsanyi >Priority: Major > Labels: BigQuery, GCP > Fix For: 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The new PutBigQuery processor targeting the new Write API introduced as part > of this ticket: https://issues.apache.org/jira/browse/NIFI-10403 should be > extended with Proxy Configuration Service capability. As discussed on an > earlier PR Proxy configuration needs to be added on gRPC level as well which > could be a more involved effort: https://github.com/apache/nifi/pull/6580 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12897) Allow users to upload files/resources to nifi for use in the dataflow
[ https://issues.apache.org/jira/browse/NIFI-12897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827170#comment-17827170 ] Pierre Villard commented on NIFI-12897: --- Can details be shared on what is going to be the approach here? what are the options that have been evaluated, etc? Maybe I didn't look in the right place but I didn't see anything proposal in [https://cwiki.apache.org/confluence/display/NIFI/Product+requirements]. This could bring a lot of questions so just want to make sure we can discuss the details and I don't see any description in NIFI-12898. > Allow users to upload files/resources to nifi for use in the dataflow > - > > Key: NIFI-12897 > URL: https://issues.apache.org/jira/browse/NIFI-12897 > Project: Apache NiFi > Issue Type: Epic > Components: Core Framework, Core UI >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > > A common feature request that we receive is to make it easier to upload a > resource file, such as JDBC Driver JAR to nifi so that all of the nodes > receive the file. This epic is meant to capture that request -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12886) Upgrade Jackson JSON to 2.16.2
[ https://issues.apache.org/jira/browse/NIFI-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12886: -- Fix Version/s: 2.0.0 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jackson JSON to 2.16.2 > -- > > Key: NIFI-12886 > URL: https://issues.apache.org/jira/browse/NIFI-12886 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Jackson JSON libraries should be upgraded to > [2.16.2|https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.16.2] to > incorporate several minor bug fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12840) Expose REMOTE_POLL_BATCH_SIZE property for ListSFTP
[
https://issues.apache.org/jira/browse/NIFI-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-12840.
---
Fix Version/s: 1.26.0
Resolution: Fixed
> Expose REMOTE_POLL_BATCH_SIZE property for ListSFTP
> ---
>
> Key: NIFI-12840
> URL: https://issues.apache.org/jira/browse/NIFI-12840
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.25.0
>Reporter: endzeit
>Assignee: endzeit
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Backport changes from NIFI-12772 into the _support/nifi-1.x_ branch by
> exposing the property {{REMOTE_POLL_BATCH_SIZE}} for {{ListSFTP}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12871) Upgrade Commons Compress to 1.26.1
[ https://issues.apache.org/jira/browse/NIFI-12871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12871: -- Fix Version/s: 2.0.0 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons Compress to 1.26.1 > -- > > Key: NIFI-12871 > URL: https://issues.apache.org/jira/browse/NIFI-12871 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: Michael W Moser >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Commons Compress has released version > [1.26.0|https://commons.apache.org/proper/commons-compress/changes-report.html#a1.26.0] > which is a minor feature and maintenance release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12876) Update Maven Surefire Plugin to 3.2.5
[ https://issues.apache.org/jira/browse/NIFI-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12876: -- Fix Version/s: 2.0.0 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Update Maven Surefire Plugin to 3.2.5 > - > > Key: NIFI-12876 > URL: https://issues.apache.org/jira/browse/NIFI-12876 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Maven Surefire Plugin for unit test execution should be upgraded to > [3.2.5|https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354100] > to incorporate recent bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12874) Upgrade Log4j 2 to 2.23.0
[ https://issues.apache.org/jira/browse/NIFI-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12874: -- Fix Version/s: 2.0.0 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Log4j 2 to 2.23.0 > - > > Key: NIFI-12874 > URL: https://issues.apache.org/jira/browse/NIFI-12874 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0, 1.26.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Apache Log4j 2 dependencies should be upgraded to > [2.23.0|https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-23-0] > to align with the currently available version. Log4j 2 dependencies are > limited to API dependencies from several extension components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12872) Upgrade Groovy to 4.0.19
[ https://issues.apache.org/jira/browse/NIFI-12872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12872: -- Fix Version/s: 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Groovy to 4.0.19 > > > Key: NIFI-12872 > URL: https://issues.apache.org/jira/browse/NIFI-12872 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Groovy dependencies should be upgraded to > [4.0.19|http://groovy-lang.org/changelogs/changelog-4.0.19.html] on the main > branch to incorporate minor bug fixes and improvements for the Groovy-based > scripted Processors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12869) Bump langchain from 0.1.2 to 0.1.11
[ https://issues.apache.org/jira/browse/NIFI-12869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12869. --- Resolution: Fixed > Bump langchain from 0.1.2 to 0.1.11 > --- > > Key: NIFI-12869 > URL: https://issues.apache.org/jira/browse/NIFI-12869 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Bump langchain from 0.1.2 to 0.1.11 in > /nifi-python-extensions/nifi-text-embeddings-module/src/main/python/vectorstores -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12869) Bump langchain from 0.1.2 to 0.1.11
Pierre Villard created NIFI-12869: - Summary: Bump langchain from 0.1.2 to 0.1.11 Key: NIFI-12869 URL: https://issues.apache.org/jira/browse/NIFI-12869 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Fix For: 2.0.0 Bump langchain from 0.1.2 to 0.1.11 in /nifi-python-extensions/nifi-text-embeddings-module/src/main/python/vectorstores -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12868) Upgrade Commons DBCP to 2.12.0
[ https://issues.apache.org/jira/browse/NIFI-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12868: -- Fix Version/s: 2.0.0 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons DBCP to 2.12.0 > -- > > Key: NIFI-12868 > URL: https://issues.apache.org/jira/browse/NIFI-12868 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Commons DBCP dependencies should be upgraded to > [2.12.0|https://commons.apache.org/proper/commons-dbcp/changes-report.html#a2.12.0] > to incorporate several minor bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12846) AWS Assume Role Credentials with VPCE Endpoint URL cannot handle the Region
[
https://issues.apache.org/jira/browse/NIFI-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12846:
--
Fix Version/s: 1.26.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> AWS Assume Role Credentials with VPCE Endpoint URL cannot handle the Region
>
>
> Key: NIFI-12846
> URL: https://issues.apache.org/jira/browse/NIFI-12846
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.25.0
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 1.26.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In case of custom Endpoint URLs, the AWS client library may be able to parse
> the Region from the URL but can not handle VPCE URLs (e.g.
> [https://vpce-{*}-{*}***-eu-central-1a.sts.eu-central-1.vpce.amazonaws.com).|https://vpce-%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A%2A-%2A%2A%2A%2A%2A%2A%2A%2A-eu-central-1a.sts.eu-central-1.vpce.amazonaws.com)./]
> {code:java}
> 2024-02-27 13:13:04,102 ERROR [Timer-Driven Process Thread-1]
> o.apache.nifi.processors.aws.s3.ListS3
> ListS3[id=d5e08c19-a155-3b34-e9e6-dbd70e048cd1] Failed to list contents of
> bucket
> com.amazonaws.services.securitytoken.model.AWSSecurityTokenServiceException:
> Credential should be scoped to a valid region. (Service:
> AWSSecurityTokenService; Status Code: 403; Error Code: SignatureDoesNotMatch;
> Request ID: 7820b219-dee5-4989-8d0c-46523
> 1469705; Proxy: null)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1879)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleServiceErrorResponse(AmazonHttpClient.java:1418)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1387)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1157)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:814)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:781)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:755)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:715)
> at
> com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:697)
> at
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:561)
> at
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:541)
> at
> com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.doInvoke(AWSSecurityTokenServiceClient.java:1731)
> at
> com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.invoke(AWSSecurityTokenServiceClient.java:1698)
> at
> com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.invoke(AWSSecurityTokenServiceClient.java:1687)
> at
> com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.executeAssumeRole(AWSSecurityTokenServiceClient.java:532)
> at
> com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.assumeRole(AWSSecurityTokenServiceClient.java:501)
> ... {code}
> Use the explicit Region property (added in NIFI-10791) for VPCE endpoints.
> The issue affects the 1.x line only. In NiFi 2.0, the AWS processors
> (including the credential handling) have been refactored (NIFI-12144).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
