In my experience, yes it really does depend on the number of client/source locations you are talking about managing. It is my understanding that the NiFi team is definitely working towards a full “command and control” model, however, it’s not quite there yet. I have done some interesting things around creating a flow that updates the configuration of the MiniFi device and managing it that way…basically I have a flow that updates the configuration, and I have a flow that does the data transfer…that way I can deal with the configuration management from that perspective (If you are using MiniFi).
Additionally, if you have a device management strategy, there are a lot of things that can be orchestrated with regards to minifi[1] external to the solution. What I mean by this is that, outside of flow management, there are still other concerns around OS updates / JVM updates/ NiFi updates etc…and this is not something that NiFi should ever really tackle (in my opinion) as there are other device management solutions out there…and should be used. If you are looking at using full NiFi as the clients/sources you can look at the registry project[2] for flow versioning…which is pretty awesome. Still the device management mentioned above still applies. Hope this helps! [1] - https://nifi.apache.org/minifi/ <https://nifi.apache.org/minifi/> [2] - https://nifi.apache.org/registry.html <https://nifi.apache.org/registry.html> Regards, Chris > On Oct 17, 2018, at 9:12 AM, Alan O'Regan <[email protected]> wrote: > > one concern I have is having to have Nifi running on all of the client/source > locations. That could be a lot of Nifi Instances to manage! > Considered writing the new rows to a location (in json or csv) so that they > could either be pushed to a bucket that the Azure nifi could read from or > have the Azure nifi reach out and pull from those client locations. >
