I tried to attach images to the body of the email but they are in the attached files down below, sorry for the inconvenience.
On 2025/11/10 11:18:08 Paminos Sym wrote: > Hello everyone, > > Let me start by describing how we use NiFi: We have many different types of > flows of which exist multiple instances, each with its own parameter context. > For example, flow A may have 15 instances and flow B another 15. Each flow is > version controlled using NiFi Registry and is composed of a few process > groups that are usually each also version controlled. Flows go into a flow > bucket, while the process groups they are made up of go into a process group > bucket. Essentially it is similar to having an Abstract object (flow) > composed of other abstract objects (internal process groups). Every time we > create an instance, this object and the ones composing it are all > instantiated by getting parameters. > > [cid:1526dc04-96ea-4126-9b7d-e1f9bef73ad1] > > Until our recent upgrade to 2.6.0 this was functional and working mostly as > expected. To create a new instance of Flow A I would get one from the > registry, change the name, create a new parameter context, and I very quickly > had a new clone of flow A with different parameters. Now when I get a new > instance from the registry with "Keep existing Parameter Contexts" checked I > get this error: > [cid:96253bad-a86f-4df6-b0ae-d393226be779] > (I can't share the parameter context names) > I believe this has something to do with how our parameter contexts are > organized. There is a "Root Parameters" context which both Flow A and Flow B > inherit. Flow A and Flow B both have their "super" contexts (like > "super-flow-a-parameters") which inherit the Root Parameters context, and the > super contexts are inherited by the instance specific context. Then each > instance and the process groups within will use the instance specific > context. This base.sourceType parameter belongs to an instance specific > parameter context and is inherited from the root parameters context, and is > blocking my operation, but the issue is that there is no reason for this > parameter to be updated when I create a group. Creating a new group shouldn't > change the value of a parameter, so why is it trying to update this one? > > To bypass this I create the group with the "Keep existing Parameter Contexts" > unchecked, however this creates copies of some contexts (e.g. > "flow-a-instanceA (1)", "flow-a-instanceA (2)"). > > [cid:3a645302-57ad-4138-99c0-5a12a054dbe5] > > After deleting the superfluous copies of the parameter contexts and creating > the new instance's parameters I try to change the whole group's parameters. > Reminder: This is the instance's group, which is under Flow A's version > control, and contains process groups that are also version controlled. > Before, to do this I would simply click "configure" on my group, select my > parameter context, select "Apply Recursively", and after pressing apply it > would work as expected. Now I get an error: > [cid:9e6f1b00-6421-419e-bffa-e03b5f6db4e7] > This seems very strange, not only because this used to work without any > issue, but also because switching parameter contexts on a versioned flow > being a problem seems completely wrong. My work-around for the time being is > to uncheck "Apply Recursively" and manually apply the correct context in each > of the internal process groups, which is time consuming and error prone. > > The final issue I have encountered thus far is more minor. Previously, if I > made a change to a versioned flow and wanted to update every flow with that > version I would simply go to each one, running or not, and select "change > version". Though time consuming it was a frictionless procedure. Now I get an > error similar to the first one, and the work-around is to stop the flow I'm > updating, change flow version, and start it again. This makes it even more > time consuming but at least it's more manageable. > > I find it hard to believe that this is intended behaviour. Is it because we > updated from 2.2.0 straight to 2.6.0? Is this something others have > experienced? > > Any help or explanation would be greatly appreciated, thank you. > > Epameinondas Symeonidis, > Ianic S.A. > >
