Support Questions
Find answers, ask questions, and share your expertise
Announcements
Check out our newest addition to the community, the Cloudera Innovation Accelerator group hub.

Store the variables of subgroups into registry

New Contributor

We're using the NiFi Registry to store our flows. Some of them have subgroups inside them, with variables defined on that subgroups, - the thought was that this subgroups will be reusable with only these variables changing. I.e., the structure is of the following shape:

group under version control
|-subgroup A
|-variable with value A1 |-subgroup A
|-variable with value A2
We don't want to store these subgroups under version control too, because it would be just too much work. But the problem is that, when we change the values A1 and A2 and commit the top group, the subgroup variables aren't updated in registry, we have to delete the whole registry entry and recreate it from scratch. Is this the correct behaviour?
1 ACCEPTED SOLUTION

This behavior is currently how it is designed to work.

The presence of variables is captured with their initial value at the time, but then changes to the variable values do not trigger changes to be committed. The idea is that you create your flow in one environment with some number of variables, then promote it to another environment and change the variable values to be whatever is needed for the new environment, which should not require anything to be committed back to registry.

View solution in original post

2 REPLIES 2

This behavior is currently how it is designed to work.

The presence of variables is captured with their initial value at the time, but then changes to the variable values do not trigger changes to be committed. The idea is that you create your flow in one environment with some number of variables, then promote it to another environment and change the variable values to be whatever is needed for the new environment, which should not require anything to be committed back to registry.

Guru

Just wanted to add for awareness that there are other actions that are not considered local changes. From the NiFi User Guide (https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#managing_local_changes):

  • disabling/enabling processors and controller services
  • stopping/starting processors
  • modifying sensitive property values
  • modifying remote process group URLs
  • updating a processor that was referencing a non-existent controller service to reference an externally available controller service
  • modifying variables