You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "John Wise (Jira)" <ji...@apache.org> on 2021/02/26 14:05:00 UTC

[jira] [Commented] (NIFI-7986) Add UI to view and update assigned parameter context for each nested process group.

    [ https://issues.apache.org/jira/browse/NIFI-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291665#comment-17291665 ] 

John Wise commented on NIFI-7986:
---------------------------------

We use variables specifically because they are inheritable by nested process groups.  Parameters are a non-starter for us specifically because they aren't inheritable.  Managing parameter contexts in multiple nested levels would be an administrative nightmare for us.

> Add UI to view and update assigned parameter context for each nested process group.
> -----------------------------------------------------------------------------------
>
>                 Key: NIFI-7986
>                 URL: https://issues.apache.org/jira/browse/NIFI-7986
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core UI
>    Affects Versions: 1.10.0, 1.12.0, 1.11.4, 1.12.1
>            Reporter: George Knaggs
>            Priority: Minor
>
> Currently the assigned parameter context for a process group can only happen from its "Configuration" window.  The scope of the parameter context only applies to processors and service controllers directly within that process group that it is assigned, excluding any nested process groups, which may have a different or no parameter context assigned.  This is remarkably different than how scoping worked with variables, which had an inheritance model.  The nature of these differences makes it important for users when making a copy of a flow or importing a flow from the NiFi Registry, that contains nested process groups, that the entire flow must be navigated and for each nested process group open the configure window to check and possibly change the assigned parameter context. The use of nested process groups had the advantage of keeping flows easy to read, monitor, and maintain, but now are a disadvantage if you want to parameterize your flows.
> This issue was also highlighted in "Better Support for Parameterizing Flows" under NiFi Feature Flows confluence blog.  Specifically under "Import Flow" section:
> {code:java}
> 4. If there are nested Process Groups in the flow, the UX will need to provide a way to specify which Parameter Context should be used for each of those, since Parameter Contexts are not inherited, and because the intent of the original flow was to use a separate context as well.  This could be done either by showing a hierarchy of the Process Groups and choosing a Parameter Context for each, or by showing a listing of Parameter Context Names that are referenced in the flow pulled from Registry and allowing the user to map each of those names to a locally defined Parameter Context.
>  Note that this user experience for importing the flow addresses both of the key use cases: Migration of flow from dev to test to prod, as well as the need to create parameterized flows (i.e., import the same flow multiple times into the same environment, each with different parameters). Each time the user imports the flow, they can choose a new set of parameters to use.{code}
> I propose a change to the configuration window for a processs group, add a "Parameter Contexts" tab, which shows all nested process groups by name in a list with a scope/path/breadcrumb to help identify, and also showing its assigned parameter context.  From here the user can check if the correct parameter context is assigned to the nested process groups.  There could then be a drill in arrow ↘︎ icon for quickly drilling to the Configuration window for the nested process group so the user can change the assigned parameter context. It may not be feasible to navigate back to make additional changes, so alternatively, the UI could allow the change of the assigned parameter context from the parent process group for any nested process group.
> Added bonus, the same concept could be used within the Controller Services tab to show controllers services assigned to nested process groups, quickly identifying which controller services are disabled or invalid, which is also a pain when starting up flows with many nested process groups.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)