Pierre Villard created NIFI-15829:
-------------------------------------
Summary: Support parameter value references to provided parameters
from inherited parameter contexts
Key: NIFI-15829
URL: https://issues.apache.org/jira/browse/NIFI-15829
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Reporter: Pierre Villard
Assignee: Pierre Villard
When using Parameter Providers to bring parameters from external stores, the
parameters are typically managed by a separate team or system. These external
stores often enforce specific naming conventions that may differ from what is
used in NiFi flows.
For example, a flow might reference a parameter named {*}My Parameter{*}, but
the Parameter Provider creates a parameter named *My_Parameter* due to naming
constraints of the external store. Since there is no way to rename parameters
created by a Parameter Provider, users currently have two undesirable options:
# Modify the flow definition directly to change all parameter references to
match the provider's naming convention. This is extremely complicated,
especially in large flows with many references.
# Accept the naming mismatch and manually duplicate values between contexts,
defeating the purpose of using a Parameter Provider.
Both options break the user experience, particularly with versioned flows.
Changing a parameter reference in a flow is treated as a local modification,
creating noise in version control and complicating flow promotion across
environments.
*Proposed Solution*
Allow a parameter's value to be a one-to-one reference to another parameter
using the *#\{parameterName}* syntax, subject to the following constraints:
* The referenced parameter must be provided by a Parameter Provider (i.e.,
come from a Parameter Context backed by a Parameter Provider).
* The entire parameter value must be exactly *#\{parameterName}* – no mixed
text, no multiple references.
* Sensitivity must match: a non-sensitive parameter can only reference a
non-sensitive parameter, and a sensitive parameter can only reference a
sensitive parameter. On mismatch, the reference is left unresolved.
* No chaining: only one level of indirection is supported. This keeps the
behavior predictable and avoids circular reference concerns.
*Example*
A Parameter Provider creates a Parameter Context S with a parameter {*}db_host
= "myserver.example.com"{*}. A user-managed Parameter Context P inherits from S
and defines a local parameter {*}host = #\{db_host}{*}. When a component in the
process group references {*}#\{host}{*}, it resolves to
{*}"myserver.example.com"{*}.
If the Parameter Provider updates *db_host* to a new value, all components
referencing *#\{host}* are properly notified and restarted, exactly as if
*host* had changed directly.
*Benefits*
* Decouples flow definitions from provider naming constraints. Flows can use
human-readable parameter names while providers use their own conventions.
* Preserves versioned flow integrity. Parameter name mapping is defined in the
Parameter Context, not in the flow itself, so no local modifications are
created.
* Centralizes configuration mapping. Administrators configure the mapping once
in the Parameter Context; flow developers are unaffected.
* Scoped to provider-sourced parameters. References only resolve when the
target parameter is provided by a Parameter Provider, making the feature
predictable and preventing fragile reference chains between manually-managed
contexts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
