Hi Mike, Yes, this is expected behavior.
Let's say I have a PG A that has a nested versioned PG B, both are at version 1. Because PG B is versioned, the full definition of PG A does not extend down into PG B, it stops at a reference to "PG B:v1". Because PG B is versioned independently, a reference to that versioned PG id at version number fully defines PG A. Let's say I change the definition of PG B. PG B will show up on my canvas as "version 1 with local changes", but until I commit those changes, it is still at version 1 (modified), so PG A is still defined both locally and in NiFi Registry as "containing PG B:v1". Therefore, PG A, at this point in time, does not have any local changes (because compared to Registry, it has the same definition), which is why it shows up as such. Once I commit PG B's local changes, PG B on my canvas is now at version 2, and my local PG A's definition has changed to include a reference to PG B:v2. This differs from what is in Registry for PG A:v1, so now PG A shows local changes. If I revert local changes, I will go back to PG A:v1 referencing PG B:v1. If I commit local changes, PG A is now also at version 2, which references PG B:v2. Fair to say this can be surprising/confusing behavior at first, even though technically correct. This is why the top level version indicators on the global status bar are useful to see if there are any changes, nested or otherwise, in the overall flow. Best, Kevin On Wed, Jul 18, 2018 at 9:24 PM, Mike Thomsen <[email protected]> wrote: > We have 0.2 hooked up to a NiFi instance that has nested PGs. All PGs are > versioned. When one of the inner ones has local changes, the out of sync > icon doesn't appear on the parent PGs. Is that expected behavior? No one > really minds it, but I didn't have an answer as to whether we stumbled onto > a bug or it's expected behavior. > > Thanks, > > Mike >
