nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre F de Miranda <>
Subject Re: Kafkaesque Output port
Date Fri, 17 Mar 2017 02:51:29 GMT

Another point for consideration is the scope of this information.  Core
NiFi flows and those components are very much about data whereas those IPs
may not necessarily be data for consumption, per se, but context that
governs how the data flow is operating.  In this case, there is a different
plane of information exchange and may deserve a discrete logical channel to
make this available.

Not sure what you mean by governing the context but maybe I should explain
myself a bit better: from a NiFi point of view the data (IPs)  are still
data to be consumed, the only difference in this case is that the data is
very small and the final delivery mechanism is a Unix command (instead of a
PutElasticSearch processor for example)

The fact we update firewall ACL from the sensors themselves is relatively
irrelevant to the overall flow.

As an example: The IPs could be sent  from sensors m1 and m2 to core and
then to a completely independent set of sensors mm1-mmN where the same data
is simply saved into disk (instead of running ExecuteScript).

I may be wrong but I was under the impression that from a minifi point of
view, what we do with the data at the end of the data flow is not a matter
of relevance, if so, then at least in this case, this would still count as
"data in movement scenario" that we try to cover.

Would you agree?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message