@alan18080  The Single-User-Provider for authentication was not intended for production use. It is a very basic username and password based authenticator that support only a single user identity.  When you access the UI of a NiFi node, you are authenticating with only that node.  The provider generates a client token which your browser holds and a corresponding server side token/key held only by the node you authenticated with.    This is why you need to use sticky sessions (Session Affinity) in your load-balancer so that all subsequent request go to same NiFi server.  There is no option in NiFi that would allow that client JWT token to be accepted by all nodes in a NiFi cluster because of the uniqueness of the JWT generated token to a specific node. Related: NIFI-7246 Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@alan18080  NiFi-Registry only pushes to the GitFlowPersistenceProvider while running.  NIFi-Registry will only read from Git on startup.  The GitFlowPersistence Provider also only contains the flow definitions for the version controlled process groups.  Each NiFi-Registry has a metadata database maintains the knowledge of which buckets exist, which versioned items belong to which buckets, as well as the version history for each item.  So if you are trying to share a single Git Repo across multiple running NiFi-Registry instances this will explain why you are seeing missing versions at times across your multiple instances. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more