[
https://issues.apache.org/jira/browse/NIFI-15475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18052433#comment-18052433
]
Pierre Villard commented on NIFI-15475:
---------------------------------------
Thanks for filing this issue [~goofwithz3].
Regarding the comment in point 4. This is because, with git-based registry
clients, we are checking for latest status of the versioned process groups at a
frequency of 30 minutes by default. This was a request from the community for
users with a lot of versioned process groups to not hit the rate API limits of
the git provider. The change was made in NIFI-14355 (if you want to read the
discussion about it). However, in NIFI-14728, a property is exposed to change
this default value to something that is better matching your needs.
{code:java}
nifi.flowcontroller.registry.sync.interval=30 min {code}
So this is what you could use to solve the comment in point 4 based on your
needs and your scenario (as well as your rate limits).
Now, regarding the comment you make in point 6, I do agree this is a bug. We
should not let someone commit changes without checking first that no new
versions have been committed in between. Otherwise that would just override the
changes. I'll look into that.
I do want to note however that with the branching capabilities, I'd expect the
processes to be a slightly different: if multiple people are working on the
same flow, they would each create their branch for the work they're doing, then
commit their changes on their respective branches and submit pull requests to
have the changes merged into the main branch (to then be deployed to upper
environments).
> Versioned ProcessGroups are still sometimes not in sync with Flow Registry
> --------------------------------------------------------------------------
>
> Key: NIFI-15475
> URL: https://issues.apache.org/jira/browse/NIFI-15475
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Geoff Greene
> Priority: Major
>
> This looks like it is very related to NIFi-14478, but its still happening in
> 2.7.2:
> So, under the assumption that nifi-registry [which we rely quite heavily on]
> is going to go away, I looked at the replacement, which I gather is
> GitlabFlow Registry client (with a gitlab backing store)
> With both nifi 2.7.2 and nifi 2.6.0:
>
> # Create a simple flow, and check it into the Gitlab FlowRegistry.
> # Reimport that flow, so we now have TWO identical copies of that flow
> # Change one copy of the flow, and check it in
> # The red upgrade needed flag in the upper left corner of the OTHER flow
> doesn’t appear after many minutes. The greene checkmark remains on both,
> even though one is out of date. This is really bad for us.
> # Eventually the red upgrade flag appears SOMETIMES, but not consitsently
> # Unfortunately, and to make things worse, if you then attempt to make
> another change in the pasted OTHER flow, it doesn’t recognize the conflict,
> and that change actually overwrites the change you made in step 3.
> For what its worth, this does not appear to be the case using regular (old)
> nifi-registry.
> Restarting nifi between steps 3 and 4 does make the red upgrade flag appear,
> even in 2.7.2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
