Re: Committing to the metron-bro-plugin-kafka repo

2017-11-09 Thread zeo...@gmail.com
Whups, here is a correctly updated roadmap. Also, the METRON-1309 PR is out and I've completed my testing so it's ready for review: 1. *DONE* - Move the bro-plugin-kafka to its own repository (Prereq to METRON-813). 2. *PR OPEN* - Update metron-deployment to pull the plugin from

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-08 Thread zeo...@gmail.com
I'm not strongly against it, but my biggest interest was not wasting time doing something that will get ripped out fairly quickly. That said, discussing this is taking more time than doing the work, and I should have a PR out soon that does what you requested as soon as my full-dev tests

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-08 Thread Nick Allen
Let me put the sub-module discussion aside for a second. I don't really have much of an opinion on that quite yet. I need to research it a bit more, but thanks for sharing the pros/cons. My main point is that I would like to see us update our deployment code to deploy the Bro plugin from the

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-08 Thread zeo...@gmail.com
So, here's my argument against the sub-module approach: - If we add a sub-module into apache/metron then the way you clone from github changes (--recursive). This could break any instructions to spin up Metron full-dev, when they're using the bro plugin (forums, blog posts, metron READMEs, etc.).

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-08 Thread Nick Allen
‚ÄčI would suggest that we shift our existing deployment routines to use the new code repository, prior to making changes to "packag-ify" it. That way we know that our code reorganization is definitely working and has been successful. Prior to step 2, we would... * Add a sub-module pointing to

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-07 Thread zeo...@gmail.com
So here's an update on this, and I'm looking for any suggestions regarding the roadmap. If anybody isn't clear about the implementation specifics or history here, I'm happy to reiterate, but it has also been discussed on the mailing list in the past. Right now, we have a direct migration of

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-07 Thread Nick Allen
> As of bro-pkg 1.1, I need to redo my `bro-pkg.meta` work to support the > newly-added `external_depends`, and also upgrade to bro 2.5.2 Isn't upgrading to 2.5.2 an enhancement that we need to wait on before we finish some clean-up tasks? What all do you think we need to do before we start

Re: Committing to the metron-bro-plugin-kafka repo

2017-11-06 Thread zeo...@gmail.com
Sorry for the delay here - I pushed this out tonight (link , link ). As of bro-pkg 1.1, I need to redo my `bro-pkg.meta` work to support the newly-added

Re: Committing to the metron-bro-plugin-kafka repo

2017-09-18 Thread Nick Allen
Nice! Looks good to me. On Mon, Sep 18, 2017 at 11:35 AM zeo...@gmail.com wrote: > Okay, I took a stab at it this morning, can I get a double check before > pushing it out? The latest commit would be opened as a PR. > >

Re: Committing to the metron-bro-plugin-kafka repo

2017-09-15 Thread zeo...@gmail.com
Good point, I can take that task re migrating the revision history of the folder. Jon On Fri, Sep 15, 2017, 12:14 Nick Allen wrote: > Hi Jon - > > I agree with you on the approach. We should first copy everything as it is > to the new repo. We should maintain the revision

Re: Committing to the metron-bro-plugin-kafka repo

2017-09-15 Thread Nick Allen
Hi Jon - I agree with you on the approach. We should first copy everything as it is to the new repo. We should maintain the revision history too. I'm sure there is a way to do it, but would have to research a bit. Then we apply your changes on top of that. Thanks On Thu, Sep 14, 2017 at

Committing to the metron-bro-plugin-kafka repo

2017-09-13 Thread zeo...@gmail.com
So, I've been working on METRON-813 lately and I have an initial run at it ready to go here (squashed history, see a better history there