[
https://issues.apache.org/jira/browse/NIP-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIP-7:
-------------------------------
Description:
h1. Motivation
The framework
[AuditService|https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/AuditService.java]
interface supports storage and retrieval of Flow Configuration History Actions
using a local persistence implementation based on JetBrains Xodus. The
implementation supports viewing changes within the NiFi application using the
Flow Configuration History screen, but does not provide an option to send
Action information to other destinations at the time the Action occurs.
Introducing a new Flow Action Reporter interface as a framework extension
interface would support external tracking through custom solutions. The Flow
Action Reporter interface should be limited to receiving flow action objects,
supporting external export of Flow Configuration History. A new framework
extension enables low-latency export of security-relevant events with a narrow
set of application changes required.
h1. Scope
The new Flow Action Reporter interface should be defined in the
{{nifi-framework-api}} module as opposed to the {{nifi-api}}. The
{{nifi-framework-api}} does not have the same level of compatibility
requirements as the public {{nifi-api}}, but provides sufficient stability of
framework components. The Flow Action Reporter would follow the same pattern as
the Status History Repository and Authorizer interfaces, both of which are
located in the {{nifi-framework-api}}. Defining the Flow Action Reporter
interface as an extension will require changes to extension loading, and
adjustments to {{AuditService}} references.
The {{Action}} interface includes the authenticated user identity, but does not
include additional details from the HTTP request, such as the client address or
user agent. This information is important to provide a complete description of
the context related to flow configuration changes. The {{nifi-web-security}}
module builds on Spring Security and makes some of the HTTP information
available, requiring additional changes to support associating Flow Actions
with HTTP request attributes.
h1. Compatibility
Introducing the Flow Action Reporter as a new framework extension will maintain
compatibility with existing deployments and will not require a new major
version. The default behavior will continue to work based on the JetBrains
Xodus repository without requiring any new configuration properties.
h1. Description
The Flow Action Reporter interface should be defined in the
{{nifi-framework-api}} module and support the following minimum methods:
1. void onConfigured(FlowActionReporterConfigurationContext context)
2. void reportFlowActions(Collection<FlowAction> flowActions)
3. void preDestruction()
The {{onConfigured()}} method enables implementations to initialize
collaborating components, such as network client services. The
{{preDestruction()}} method enables implementations to close network client
services or other resources. The {{FlowActionReporterConfigurationContext}}
should include a method for retrieving an optional {{SSLContext}} loaded from
application security properties, enabling TLS communication with external
services when required.
The {{reportFlowActions()}} method serves as the primary method for receiving
Flow Actions. The method does not return any status or support any checked
exceptions, indicating that the framework does not support tracking or retrying
action reporting. The {{FlowAction}} object should be defined in the
{{nifi-framework-api}} as an interface similar to the {{Action}} interface in
{{nifi-api}}. The {{FlowAction}} interface should include additional properties
for relevant HTTP request information, and provide a more generic structure for
Action Details as opposed to the current class and subclass hierarchy.
Following an approached based on a Map aligns with other conventions like
FlowFile attributes, making it easier for implementations to handle new
properties. The framework implementation will be responsible for translating
{{Action}} objects to {{FlowAction}} objects prior to calling
{{reportFlowActions()}}.
Instances of the Flow Action Reporter will be loaded using standard NAR bundle
packaging.
The Flow Action Reporter will be configured using a new application property in
{{nifi.properties}} that specifies the full class name to be loaded.
h1. Verification
Verifying the changes should include a combination of unit tests and system
tests. Unit tests should cover localized behavior changes, and a new system
test should exercise a custom implementation.
h1. Alternatives
The first alternative to a narrow Flow Action Reporter is a complete Flow
Action Repository extension. This approach would follow the pattern of other
Repository extension interfaces, but would require more substantial work to
implement a custom solution. Managing the lifecycle of Flow Actions requires
additional resource considerations, outside the scope of simple reporting.
Although custom repository implementations could chose not to implement certain
methods, such an approach would break the behavior of the Flow Configuration
History screen and corresponding REST API. Introducing the scoped Flow Action
Reporter does not preclude future improvements to support a complete Flow
Action Repository.
The second alternative to a new Flow Action Reporter is using a custom
Reporting Task to retrieve flow changes. Although this approach could be
implemented as an extension within current framework capabilities, it has
several limitations. The Flow Configuration History allows an authorized user
to purge the history, which could cause a Reporting Task to miss relevant
actions. In addition, a Reporting Task requires periodic invocation,
introducing potential latency for action reporting. Reporting Tasks are also
user-facing extensions as opposed to framework extensions. With the goal of
externalized action tracking, a framework extension provides better alignment
as an infrastructure concern.
was:
h1. Motivation
The framework
[AuditService|https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/AuditService.java]
interface supports storage and retrieval of Flow Configuration History Actions
using a local persistence implementation based on JetBrains Xodus. The
implementation supports viewing changes within the NiFi application using the
Flow Configuration History screen, but does not provide an option to send
Action information to other destinations at the time the Action occurs.
Introducing a new Flow Action Reporter interface as a framework extension
interface would support external tracking through custom solutions. The Flow
Action Reporter interface should be limited to receiving flow action objects,
supporting external export of Flow Configuration History. A new framework
extension enables low-latency export of security-relevant events with a narrow
set of application changes required.
h1. Scope
The new Flow Action Reporter interface should be defined in the
{{nifi-framework-api}} module as opposed to the {{{}nifi-api{}}}. The
{{nifi-framework-api}} does not have the same level of compatibility
requirements as the public {{{}nifi-api{}}}, but provides sufficient stability
of framework components. The Flow Action Reporter would follow the same pattern
as the Status History Repository and Authorizer interfaces, both of which are
located in the {{{}nifi-framework-api{}}}. Defining the Flow Action Reporter
interface as an extension will require changes to extension loading, and
adjustments to {{AuditService}} references.
The {{Action}} interface includes the authenticated user identity, but does not
include additional details from the HTTP request, such as the client address or
user agent. This information is important to provide a complete description of
the context related to flow configuration changes. The {{nifi-web-security}}
module builds on Spring Security and makes some of the HTTP information
available, requiring additional changes to support associating Flow Actions
with HTTP request attributes.
h1. Compatibility
Introducing the Flow Action Reporter as a new framework extension will maintain
compatibility with existing deployments and will not require a new major
version. The default behavior will continue to work based on the JetBrains
Xodus repository without requiring any new configuration properties.
h1. Description
The Flow Action Reporter interface should be defined in the
{{nifi-framework-api}} module and support the following minimum methods:
1. void onConfigured(FlowActionReporterConfigurationContext context)
2. void reportFlowActions(Collection<FlowAction> flowActions)
3. void preDestruction()
The {{onConfigured()}} method enables implementations to initialize
collaborating components, such as network client services. The
{{preDestruction()}} method enables implementations to close network client
services or other resources. The {{FlowActionReporterConfigurationContext}}
should include a method for retrieving an optional {{SSLContext}} loaded from
application security properties, enabling TLS communication with external
services when required.
The {{reportFlowActions()}} method serves as the primary method for receiving
Flow Actions. The method does not return any status or support any checked
exceptions, indicating that the framework does not support tracking or retrying
action reporting. The {{FlowAction}} object should be defined in the
{{nifi-framework-api}} as an interface similar to the {{Action}} interface in
{{{}nifi-api{}}}. The {{FlowAction}} interface should include additional
properties for relevant HTTP request information, and provide a more generic
structure for Action Details as opposed to the current class and subclass
hierarchy. Following an approached based on a Map aligns with other conventions
like FlowFile attributes, making it easier for implementations to handle new
properties. The framework implementation will be responsible for translating
{{Action}} objects to {{FlowAction}} objects prior to calling
{{{}reportFlowActions(){}}}.
Instances of the Flow Action Reporter will be loaded using standard NAR bundle
packaging.
The Flow Action Reporter will be configured using a new application property in
{{nifi.properties}} that specifies the full class name to be loaded.
h1. Verification
Verifying the changes should include a combination of unit tests and system
tests. Unit tests should cover localized behavior changes, and a new system
test should exercise a custom implementation.
h1. Alternatives
The first alternative to a narrow Flow Action Reporter is a complete Flow
Action Repository extension. This approach would follow the pattern of other
Repository extension interfaces, but would require more substantial work to
implement a custom solution. Managing the lifecycle of Flow Actions requires
additional resource considerations, outside the scope of simple reporting.
Although custom repository implementations could chose not to implement certain
methods, such an approach would break the behavior of the Flow Configuration
History screen and corresponding REST API. Introducing the scoped Flow Action
Reporter does not preclude future improvements to support a complete Flow
Action Repository.
The second alternative to a new Flow Action Reporter is using a custom
Reporting Task to retrieve flow changes. Although this approach could be
implemented as an extension within current framework capabilities, it has
several limitations. The Flow Configuration History allows an authorized user
to purge the history, which could cause a Reporting Task to miss relevant
actions. In addition, a Reporting Task requires periodic invocation,
introducing potential latency for action reporting. Reporting Tasks are also
user-facing extensions as opposed to framework extensions. With the goal of
externalized action tracking, a framework extension provides better alignment
as an infrastructure concern.
> Add Flow Action Reporter as Framework Extension
> -----------------------------------------------
>
> Key: NIP-7
> URL: https://issues.apache.org/jira/browse/NIP-7
> Project: NiFi Improvement Proposal
> Issue Type: New Feature
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Major
>
> h1. Motivation
> The framework
> [AuditService|https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/AuditService.java]
> interface supports storage and retrieval of Flow Configuration History
> Actions using a local persistence implementation based on JetBrains Xodus.
> The implementation supports viewing changes within the NiFi application using
> the Flow Configuration History screen, but does not provide an option to send
> Action information to other destinations at the time the Action occurs.
> Introducing a new Flow Action Reporter interface as a framework extension
> interface would support external tracking through custom solutions. The Flow
> Action Reporter interface should be limited to receiving flow action objects,
> supporting external export of Flow Configuration History. A new framework
> extension enables low-latency export of security-relevant events with a
> narrow set of application changes required.
> h1. Scope
> The new Flow Action Reporter interface should be defined in the
> {{nifi-framework-api}} module as opposed to the {{nifi-api}}. The
> {{nifi-framework-api}} does not have the same level of compatibility
> requirements as the public {{nifi-api}}, but provides sufficient stability of
> framework components. The Flow Action Reporter would follow the same pattern
> as the Status History Repository and Authorizer interfaces, both of which are
> located in the {{nifi-framework-api}}. Defining the Flow Action Reporter
> interface as an extension will require changes to extension loading, and
> adjustments to {{AuditService}} references.
> The {{Action}} interface includes the authenticated user identity, but does
> not include additional details from the HTTP request, such as the client
> address or user agent. This information is important to provide a complete
> description of the context related to flow configuration changes. The
> {{nifi-web-security}} module builds on Spring Security and makes some of the
> HTTP information available, requiring additional changes to support
> associating Flow Actions with HTTP request attributes.
> h1. Compatibility
> Introducing the Flow Action Reporter as a new framework extension will
> maintain compatibility with existing deployments and will not require a new
> major version. The default behavior will continue to work based on the
> JetBrains Xodus repository without requiring any new configuration properties.
> h1. Description
> The Flow Action Reporter interface should be defined in the
> {{nifi-framework-api}} module and support the following minimum methods:
> 1. void onConfigured(FlowActionReporterConfigurationContext context)
> 2. void reportFlowActions(Collection<FlowAction> flowActions)
> 3. void preDestruction()
> The {{onConfigured()}} method enables implementations to initialize
> collaborating components, such as network client services. The
> {{preDestruction()}} method enables implementations to close network client
> services or other resources. The {{FlowActionReporterConfigurationContext}}
> should include a method for retrieving an optional {{SSLContext}} loaded from
> application security properties, enabling TLS communication with external
> services when required.
> The {{reportFlowActions()}} method serves as the primary method for receiving
> Flow Actions. The method does not return any status or support any checked
> exceptions, indicating that the framework does not support tracking or
> retrying action reporting. The {{FlowAction}} object should be defined in the
> {{nifi-framework-api}} as an interface similar to the {{Action}} interface in
> {{nifi-api}}. The {{FlowAction}} interface should include additional
> properties for relevant HTTP request information, and provide a more generic
> structure for Action Details as opposed to the current class and subclass
> hierarchy. Following an approached based on a Map aligns with other
> conventions like FlowFile attributes, making it easier for implementations to
> handle new properties. The framework implementation will be responsible for
> translating {{Action}} objects to {{FlowAction}} objects prior to calling
> {{reportFlowActions()}}.
> Instances of the Flow Action Reporter will be loaded using standard NAR
> bundle packaging.
> The Flow Action Reporter will be configured using a new application property
> in {{nifi.properties}} that specifies the full class name to be loaded.
> h1. Verification
> Verifying the changes should include a combination of unit tests and system
> tests. Unit tests should cover localized behavior changes, and a new system
> test should exercise a custom implementation.
> h1. Alternatives
> The first alternative to a narrow Flow Action Reporter is a complete Flow
> Action Repository extension. This approach would follow the pattern of other
> Repository extension interfaces, but would require more substantial work to
> implement a custom solution. Managing the lifecycle of Flow Actions requires
> additional resource considerations, outside the scope of simple reporting.
> Although custom repository implementations could chose not to implement
> certain methods, such an approach would break the behavior of the Flow
> Configuration History screen and corresponding REST API. Introducing the
> scoped Flow Action Reporter does not preclude future improvements to support
> a complete Flow Action Repository.
> The second alternative to a new Flow Action Reporter is using a custom
> Reporting Task to retrieve flow changes. Although this approach could be
> implemented as an extension within current framework capabilities, it has
> several limitations. The Flow Configuration History allows an authorized user
> to purge the history, which could cause a Reporting Task to miss relevant
> actions. In addition, a Reporting Task requires periodic invocation,
> introducing potential latency for action reporting. Reporting Tasks are also
> user-facing extensions as opposed to framework extensions. With the goal of
> externalized action tracking, a framework extension provides better alignment
> as an infrastructure concern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
