I would say that
- For each configuration parameter we want to pull in, it should be
explicitly configured through a property as well as through a controller
service that accesses the metron zk
- Transformations should not be conflated with parsing in those processors
or readers
There is no on
I was just reading this, see the IRC channel :)
On 09-Aug-18 08:21, Casey Stella wrote:
> https://www.darkreading.com/endpoint/oh-no-not-another-security-product/a/d-id/1332453
That's definitely good info, thanks for reaching out to them about it.
In terms of exposing/sharing, I don't think we have to couple them tightly
(in fact, I think we should loosen the coupling as much as possible without
forcing reimplementation of things). I think there's definitely a way to do
I think the benefits are clear. What is unclear is if the goal is to
expose or share or re-use Metron capabilities ( stellar, parsing ) in nifi
in a way that is native to nifi ( configured and managed in nifi ), where
you may not even need metron ( say you just want to parse asa ) or if the
goal
I reached out to the nifi list about the Record api ‘stability'
On August 9, 2018 at 09:54:22, Bryan Bende (bbe...@gmail.com) wrote:
I don't think there are any stability issues with the record API, it
is definitely recommended to use the record approach where it makes
sense.
That comment was
I'll add onto Mike's discussion with the original set of requirements I had
in mind (and apply feedback on these as necessary!). This is largely
overlap with what Mike said, but I want to make sure it's clear where my
proposal was coming from, so we can improve on it as needed. James and
Mike are
