Hi Aldrin, Thank you for your response. It was quite helpful to know about the C2 server. I will try out the ChangeIngestors with the help of C2 server.
Regards, Vikram On Wed, Aug 16, 2017 at 8:39 PM, Aldrin Piri <aldrinp...@gmail.com> wrote: > Hi Vikram, > > Good questions and thought out process in this email. > > Your approach seems valid and a fairly typical use case which we are > working on supporting well. > > 1) At this time, you cannot do so directly from NiFi. I think based on > some of the initial discussions and work that has been performed, the C2 > server (if you are willing to run an instance) may be a better option at > this juncture. It is currently possible to communicate with NiFi via REST > to provide configuration to instances. More info on this material is > available in the docs [1]. This will effectively do the workflow you are > seeking. The notion behind the C2 is to decouple from the specific > provider especially as work on the Registry ramps up. This would be > another, likely preferred, configuration provider. > > 2), 3) There is not currently a hot deploy mechanism to an instance and > would require a restart to incorporate the new flow. As you mention, the > change ingestors can allow an instance to consume a new configuration. In > the current state, a given configuration can run multiple, distinct > dataflows, within one instance, but these are not decoupled from the > configuration. That is to say, if I was running a first flow, Flow A, and > wanted to run a second flow, Flow B, I would create a template that adds > the functionality of Flow B to that of Flow A, and perform a deployment. > The http.query attribute allows the instance to provide information to the > server providing the configuration. An example of this is in the > integration-tests project bootstrap.conf [2]. In this case, it is allowing > the device to indicate its class with the notion being that the server I am > ingesting a change from could custom tailor the configuration that is > delivered; think of a dynamically generated resource as opposed to a static > file just downloaded from a given server. This should not concern your use > of FetchMQTT. > > 4) Not explicitly at this time. While we do support transfer of data in > both directions, these higher level operations are not yet implemented. > There are ways this could be done, but the breadth of desired C2 > functionality is not quite there yet. What you are seeking is definitely > directly inline with some of the proposed and discussed features to > include. There has been some initial discussion of initial cases on our > Wiki [3]. > > > Please let us know if anything needs additional clarification and if you > have any additional questions or comments. > > Thanks! > --aldrin > > [1] https://github.com/apache/nifi-minifi/tree/master/minifi > -c2#configuration-providers > [2] https://github.com/apache/nifi-minifi/blob/master/ > minifi-integration-tests/src/test/resources/bootstrap.conf#L60 > [3] https://cwiki.apache.org/confluence/display/MINIFI/ > Product+requirements > > > On Wed, Aug 16, 2017 at 2:36 AM, Vikram KR <vkunni...@gmail.com> wrote: > >> I have a NiFi instance on my cloud server machine and I have MinFi >> instance running on my gate way. I want to capture data from 2 different >> devices and perform some device specific logic for filtering data on the >> edge and then on the server side detect some events which should raise >> alerts. I also want to send back some control messages from server to the >> devices. >> >> >> >> My approach to this would be the following, >> >> 1) Create 2 dataflows on the NiFi side which reads from an Input port, >> check for some specific parameter value in the data and then write to Kafka >> or some other target. I want to have two different dataflow and not a >> single dataflow for a specific reason. >> >> >> >> 2) Create 2 MiniFi edge flows each of which reads from a serial port and >> then performs some filtering based on a specifc condition for each of the >> device and then writes to a remote process group. >> >> >> >> Now I want to know if I can do the following with MinFi? >> >> >> >> 1) Can I deploy the first MinFi dataflow from the NiFi UI, without >> exporting it as XML and then using the Converter tool Kit? >> >> >> >> 2) Assuming that I have Started the MiniFi with the yaml configuration >> having my MiniFi dataflow1, I want to now deploy the second MinFi dataflow >> without stopping and re-starting the MinFi instance? >> >> >> >> 3) I see that MiniFi can use the PullHttpChangeIngestor to get the >> configuration changes, >> >> If I have 2 different dataflow's running on my MinFi instance, how will I >> know which processor's configuration got changed and what property got >> changes? >> >> Also in the Minfi bootstrap conf file, what are these 2 properties? Can >> you give me an example of the http.query attribute value if I want to use >> say FetchMQTT processor on the edge? >> >> >> >> nifi.minifi.notifier.ingestors.pull.http.path=/c2/config >> >> # Query string to pull configurations with >> >> nifi.minifi.notifier.ingestors.pull.http.query= >> >> >> >> 4) Can I currently perform bidirectional communication using the >> minifi-C2 server? >> >> what I mean by bi-directional communication is, based on the data that >> comes from the device my NiFi dataflow on the server will monitor value of >> a specific parameter and when that value exceeds certain limits , I want >> to send start and stop message to my device from server side? How will I be >> able to do that with MinFi? >> > >