So, I do agree with the concern.  Is there a way to host the package within
Metron?  I definitely would like to see the modifications at
https://github.com/bro/bro-plugins/commit/b9f1f35415cb0db065348da0a5043a
8353b4a0a8 brought back into Metron and I'd love for us to host the plugin.


Thoughts?


On Thu, Mar 30, 2017 at 9:09 PM, zeo...@gmail.com <zeo...@gmail.com> wrote:

> Today I was taking a look at METRON-812
> <https://issues.apache.org/jira/browse/METRON-812>, which made me recall
> some conversations from a while back regarding where the bro kafka plugin
> should ultimately live, and how to update it.
>
> Back in METRON-348 <https://issues.apache.org/jira/browse/METRON-348> I
> brought up the fact that some important changes
> <https://github.com/bro/bro-plugins/commit/b9f1f35415cb0db065348da0a5043a
> 8353b4a0a8>
> were made to the externally hosted version of the kafka plugin, and were
> never introduced to Metron's hosted version (i.e. the one we use
> <https://github.com/apache/incubator-metron/blob/master/
> metron-deployment/roles/bro/tasks/bro-plugin-kafka.yml>
> in vagrant when bro is installed).  The conversation went down the route of
> discussing whether or not the bro kafka plugin code should continue to live
> in Metron in the first place.  Now, with METRON-812, I see us further
> muddying the waters of where to go for the right plugin, as our version is
> still missing the public changes but adds some very important new
> functionality.
>
> I'd like to bring up the idea of using bro's packages
> <https://github.com/bro/packages> framework, released in late 2016
> <http://blog.bro.org/2016/10/introducing-bro-package-manager.html>
> (additional
> documentation here <http://bro-package-manager.readthedocs.io/en/stable/
> >),
> as a potential place for this to be hosted/referenced.  This is a simple
> and supported method (funded by Mozilla
> <https://blog.mozilla.org/blog/2015/12/10/mozilla-open-
> source-support-first-awards-made/>)
> to install and uninstall bro scripts, plugins, etc., and it also allows us
> to continue to have enough control over updates to the plugin so that it
> will not slow down Metron development by having it as a dependency
> (resolving both of Casey's concerns noted here
> <https://issues.apache.org/jira/browse/METRON-348?
> focusedCommentId=15391865&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15391865>,
> and I think this solution is supported by Nick's comments here
> <https://issues.apache.org/jira/browse/METRON-348?
> focusedCommentId=15391872&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15391872>
> as
> well).
>
> The only thing I'm not sure about is where to host the plugin itself - my
> first thought would be Nick's github <https://github.com/nickwallen>, as
> he
> really kicked off this effort, but maybe we can think of something better.
>
> Is this approach of interest to anybody?  It is extremely simple to put
> together - I was able to throw one together
> <https://github.com/bro/packages/blob/master/jonzeolla/bro-pkg.index> and
> get it working with a fresh bro 2.5 install when attending the brocon talk
> <https://www.bro.org/brocon2016/brocon2016_abstracts.html#bro-
> packagemanager>
>  (recording <https://www.youtube.com/watch?v=9RFfPJeGkcE>, slides
> <https://www.bro.org/brocon2016/slides/hall_bpm.pdf>) that introduced this
> to me in the first place.
>
> Jon
> --
>
> Jon
>

Reply via email to