Hi all, It appears the NiFi Registry is the established solution for flow versioning/deployment/upgrades, however it seems to have a centralised architecture such that any server with NiFi running on it must be able to connect back to a centralised server running the Registry in order upgrade flows. My scenario is I have an isolated server that can't make external network connections, but I can transfer files to it. This means I can e.g. transfer NiFi templates to deploy into the NiFi instance, but I can't connect that NiFi back to a Registry to upgrade the flow to the next version. How do I programmatically upgrade the flow? I had a brief look at exporting some data out of my Registry into the server's Registry instance - that way I could do an upgrade by communicating to the local Registry. However I found that the h2 database was needed as part of the export, and trying to integrate multiple developers' h2 databases into one h2 database to be used by Registry seemed difficult to do in a reliable way. Are there any alternatives to either the Registry or this centralised approach for upgrading flows from e.g. version 1 to version 2???
... View more
Hi all, I'm working with standalone NiFi. I'm wondering if there's any established best practices for the deployment of templates, particularly in contexts where a NiFi Registry instance cannot be used as the environments are isolated in such a way that they would not be able to access a centralised registry. Each environment has its own unique properties, so the properties for various NiFi components (processors, controller services...) will be set to values unique to that environment. This is complicated by sensitive properties and properties that don't support the expression language (which enables the use of variables). For example, during development time of a NiFi flow, the properties that don't support EL require the use of static values that aren't applicable to other environments. This seems to require a mapping of NiFi properties to environment configuration. i.e. if we have a a processor of type "foo" then the processor property called "Username" should map to the environment configuration "baz". Is there a better way to do this? Regards, James
... View more