[
https://issues.apache.org/jira/browse/NIFI-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17085140#comment-17085140
]
Eric Secules edited comment on NIFI-7363 at 4/16/20, 6:04 PM:
--------------------------------------------------------------
[~joewitt] Is there anything else I can do to help groom this issue so that it
is ready for someone to work on and when can we expect a fix? It seems to me
like a design flaw in how parameter contexts are versioned. This is a big issue
for production deployment because the value of a parameter is based on the
order that process groups are imported. My current workaround is to version
parameter values in externally in a file and manually set them with the REST
API.
was (Author: esecules):
[~joewitt] Is there anything else I can do to help groom this issue so that it
is ready for someone to work on? It seems to me like a design flaw in how
parameter contexts are versioned. This is a big issue for production deployment
because the value of a parameter is based on the order that process groups are
imported. My current workaround is to version parameter values in externally in
a file and manually set them with the REST API.
> Deleting/Modifying Parameters with Nifi Registry
> ------------------------------------------------
>
> Key: NIFI-7363
> URL: https://issues.apache.org/jira/browse/NIFI-7363
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.11.1, 1.11.4
> Environment: NIFIREG 0.5.0
> NIFIREG 0.6.0
> Reporter: Eric Secules
> Priority: Major
>
> I am noticing that when I delete a parameter from a parameter context in NiFi
> a number of strange things result.
> * It doesn't register as a change that I can commit to the registry (the
> process group still has the green check mark)
> * When I do make a change and commit to the registry, the deleted parameter
> remains there and will be downloaded by anyone downloading the latest version
> of the flow.
> * When I look into the registry's file system, at the bottom of the
> .snapshot files I notice that each individual process group has a listing of
> parameters and their values each with slight differences from eachother. This
> is weird because the documentation says that parameter contexts are global so
> I was expecting a single parameter context entity somewhere.
> What I expect to happen:
> * When I delete or modify the value of a parameter I should be able to check
> that in in a versioned way so that newer process group versions see the
> changes but older versions do not.
> * I expected that since parameter contexts are independent of process
> groups, that they would be versioned independently of process groups.
>
> I have noticed that the parameter context gets bloated with a bunch of
> parameters that have no users and no way to delete them after doing a big
> renaming effort.
>
> Initial Investigation:
> * When I create and versioned a single process group which is the only user
> of a parameter context everything behaves as expected. Deleted parameters
> stay deleted and latest values arrive when re-importing the latest version of
> the process group on a blank canvas of a freshly restarted docker container.
> * When there are *two versioned process groups that share a single parameter
> context* what actually ends up happening is the parameter context on the NiFi
> instance is patched with the parameter contexts from the registry in the
> order that the process groups are imported. So if you delete a parameter and
> create a new version of a process gorup you also need to create new versions
> of all the process gorups that use that parameter. This wouldn't happen if
> parameters were versioned as their own entity rather than something that is
> tacked onto a process group.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
