[
https://issues.apache.org/jira/browse/NIFI-15829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-15829:
----------------------------------
Summary: Support parameter value references to parameters from inherited
parameter contexts (was: Support parameter value references to provided
parameters from inherited parameter contexts)
> Support parameter value references to 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
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
