Member since
07-30-2019
3471
Posts
1642
Kudos Received
1020
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 150 | 06-03-2026 06:06 PM | |
| 460 | 05-06-2026 09:16 AM | |
| 830 | 05-04-2026 05:20 AM | |
| 499 | 05-01-2026 10:15 AM | |
| 625 | 03-23-2026 05:44 AM |
08-03-2022
11:43 AM
@Angelvillar I think you have numerous unrelated questions here. The "GitFlowPersistenceProvider" allows you to configure a git repo in which your version controlled process groups can be pushed for persistent storage outside of NiFi Registry server's file system. What is most important here is that NiFi only reads from the git repo on service startup. While running everything is local to the NiFi-Registry server. So if some changes are manually made on the got repo, the NiFi -Registry will not see them. Additionally, the metadata about those stored versions flows is stored in the NiFi-Registry metadata-database and not in the got repo. Also keep in mind that if you created flows originally using the local file based flow provider and then switched to git repo provider, those flows will not get moved to git. Only new flows get created in git and old flows no longer are reachable. 1. Which Flow Persistence provider is configured for use in the NiFi-Registry has nothing to do with NiFi being able to connect and import flows. NiFi connects to the NiFi-Registry client URL configured in NiFi and gets a list of bucket flows to which the NiFi user has authorized access. That flow information comes from the NiFi-Registry metadata DB. So when you mad a change to the git repo, that would have had no affect until a NiFi-Registry restart. What is in the new repo also would have had no affect on what is in the NiFi-Registry Metadata DB. My guess here is that NiFi was give a list of version controlled flows known to the NiFi-Registry via the metadata DB and then when you tried to import one of them, NiFi-Registry could not find the actual flow locally. Review the "Switching from other Flow Persistence Provider" section under the metadata-database section in the NiFi-Registry docs. What changes did you make in configs when you cloned the git repo to tell NiFi to start using the new cloned repo over the original repo? If you configured git repository has existing flows committed to it, if you have nothing in the metadata-database, NiFi-registry will generate metadata for the flows imported from the flow persistence provider on NiFi-Registry startup. NiFi or NiFi-Registry being secured has nothing to do with the error you described. If NiFi was able to display a list of flows for selection to import, then connectivity to Registry seems fine. However, keep in mind that if you secure Registry, you must secure NiFi in order to write to any buckets. A secured NiFi can access a non secured NiFi-Registry and a non secured NiFi can access a non secured NiFi-Registry. It is also possible for a non secured NiFi to import flows from "public" buckets in a secured NiFi-registry. 2. It does not matter whether you run your NiFi-Registry on a VM or on Docker as long as the configured ports are reachable by your NiFi. This is all a matter of your personal preference. 3. Any Version controlled Process Group in NiFi will have a NiFi background thread that checks with NiFi-Registry to see if newer version of the PG are available. If NiFi is unable to access the NiFi-registry buckets or the persisted Flows no longer exist in NiFi-registry, you can expect to see exceptions about not being able synchronize PG with NiFi-Registry. Same would happen if you deleted the configured Registry client in the NiFi configuration and created a new Registry client pointing to same NiFi-Registry. When a NiFi-Registry client is configured that client is assigned a UUID. When a process group is version controlled, what is written to the local flow.xml.gz or flow.json.gz file is that UUID along with version controlled flow ID and version. If you delete and re-create the NiFi-Registry client it will create a new unique UUID. Your flows will not update to that new UUID, so those version controlled PGs will not be able to synchronize anymore as well. Sounds like you have been making a lot of changes and it is not clear what state everything was in before you started making changes. I'd suggest starting fresh by stopping version control on all your current PGs that have been version controlled, getting your flow persistence provider working, version control your first PG, and restart both NiFi and NiFI-registry to make sure everything is still functioning as expected. Then proceed to make one change at a time you want to try and repeat the restart to see what if anything breaks. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
08-02-2022
06:17 AM
@ZhouJun I'd recommend upgrading your NiFi to the latest release as you may be hitting these related bugs: https://issues.apache.org/jira/browse/NIFI-9835 https://issues.apache.org/jira/browse/NIFI-9433 https://issues.apache.org/jira/browse/NIFI-9761 Thank you, Matt
... View more
08-01-2022
09:07 PM
1 Kudo
@MattWho - We have separated out ebs volumes of each repos and also 3 ebs volumes each for content and provenance repos. Now looks like issue is pretty much resolved ! Thanks for all your suggestions, helped a lot Thanks Mahendra
... View more
08-01-2022
05:49 AM
@AbhishekSingh 1. @araujo response is 100% correct. 2. Just to add to @araujo respsonse here... NiFi-Registry has nothing to do with controlling what user can and can't do on the NiFi canvas. It simply allows users if it is installed to version control process groups. Even once a NiFi process group has been version controlled, authorized users in NiFi can still make changes to dataflows (even those that re version controlled). One they do make a change to a version controlled Process Group, that process group will indicate that a local change has been made and the authorized user will have the option to commit that local change as a new version of the dataflow. Controlling what users can do with dataflows is handled via authorization policies which NiFi handled very granularly. Authenticated users can be restricted to only specific Process Groups. Your NiFi admin user can setup NiFi authorization for other user per Process Group if they want by selecting the Process Group and clicking on the "key" icon in the "operate panel" on the left side of the NiFi canvas. If you found any of the responses provided assisted with your query, please take a moment to login and click on "Accept as Solution" below each of those posts. Thank you, Matt
... View more
07-22-2022
08:59 AM
Hi All, The problem was on the JDK version. We were using OpenJDK 11.0.2 which had a bug in the TLS handshake. Solution: Upgrade JDK (now using 11.0.15).
... View more
07-21-2022
01:24 AM
hi @MattWho Thanks for the reply. this is the exact information I wanted.
... View more
07-18-2022
02:02 PM
Hi Matt, thanks a lot for the explanation. I changed the path from truststore.jks to $JAVA_HOME\lib\security\cacerts on the StandardRestrictedSSLContextService settings , and worked fine !!!
... View more
07-15-2022
06:00 AM
Thanks for the reply @MattWho Firstly with the below configurations changes in authorizers.xml, I was able to store the users and their related authorization policies in database and I was able to successfully store the users and their permissions in postgresSQL database from registry <userGroupProvider> <identifier>database-user-group-provider</identifier> <class>org.apache.nifi.registry.security.authorization.database.DatabaseUserGroupProvider</class> <property name="Initial User Identity 1">DEV-ADMIN</property> </userGroupProvider> ------------------------------ <accessPolicyProvider> <identifier>database-access-policy-provider</identifier> <class>org.apache.nifi.registry.security.authorization.database.DatabaseAccessPolicyProvider</class> <property name="User Group Provider">database-user-group-provider</property> <property name="Initial Admin Identity">DEV-ADMIN</property> <property name="NiFi Identity 1"></property> <property name="NiFi Group Name"></property> </accessPolicyProvider> -------------------------------------- <authorizer> <identifier>managed-authorizer</identifier> <class>org.apache.nifi.registry.security.authorization.StandardManagedAuthorizer</class> <property name="Access Policy Provider">database-access-policy-provider</property> </authorizer> Everything is working perfect. the only need here is to get the existing users.xml and authorizations.xml data migrated to Postgres DB and we can get rid of these files. Please help
... View more
07-14-2022
09:33 AM
Thank you sir. I was able to generate more users/client certificates by specifying multiple "-C CN=user1, OU=nifi" in addition to the initial command i have.
... View more