My PR is to turn it into a package containing a plugin* On Thu, Nov 16, 2017, 08:01 zeo...@gmail.com <zeo...@gmail.com> wrote:
> The way master's full-dev is set up right now is non optimal for the bro > plugin configuration, and I would like to complete the roadmap I outlined > in my discuss thread before a release. I have a PR open against > Apache/metron-bro-plugin-kafka right now to turn it into a plugin, and I > expect it will take me until end of next week at the latest to have the > rest of the work done to move us to 2.5.2, and to pin to a specific package > version. At that point I'm comfortable with a release. > > Jon > > On Wed, Nov 15, 2017, 18:57 Matt Foley <ma...@apache.org> wrote: > >> I’ve been listening. Looks like there are still a number of major issues >> to be committed first, right? >> The discussion on this thread constitutes sufficient engagement, I think, >> especially given the Subject line :-) >> Would the folks working on the 6 issues listed by Nick care to suggest a >> cut-off date by which they’ll probably have those fixes in? >> I’ll be happy to run the release process, if the community so wishes, as >> soon as those issues are committed. >> >> I guess I should, pro forma, send the list of commits already in since >> the last release. I’ll do that today. >> Also, if anyone wishes to raise a hand and propose additional commits are >> needed, please do so on this thread. >> Thanks, >> --Matt >> >> >> On 11/15/17, 2:09 PM, "Casey Stella" <ceste...@gmail.com> wrote: >> >> I'd say that if a release is this imminent that we had better notify >> the >> release manager who will make a release announcement, Nick. Matt, >> are you >> tuning in to this? >> >> On Wed, Nov 15, 2017 at 10:04 AM, Nick Allen <n...@nickallen.org> >> wrote: >> >> > Hi Guys - >> > >> > I want to follow-up on this discussion. It sounds like most people >> are in >> > agreement with the general approach. >> > >> > A lot of people have been working hard on Metaalerts and >> Elasticsearch. I >> > have checked-in with those doing the heavy lifting and have >> compiled a more >> > detailed plan based on where we are at now. To the best of my >> knowledge >> > here is the plan of attack for finishing out this effort. >> > >> > (1) First, METRON-1289 needs to go in. This one was a fairly big >> effort >> > and I am hearing that we are pretty close. >> > >> > (2) METRON-1294 fixes an issue in how field types are looked-up. >> > >> > (3) METRON-1290 is next. While this may have been fixed in >> M-1289, there >> > may be some test cases we want from this PR. >> > >> > (4) METRON-1301 addresses a problem with the sorting logic. >> > >> > (5) METRON-1291 fixes an issue with escalation of metaalerts. >> > >> > (6) That leads us to Raghu's UI work in METRON-1252. This >> introduces the >> > UI bits that depend on all the previous backend work. >> > >> > (7) At this point, we should have our best effort at running >> Metaalerts >> > on Elasticsearch 2.x. I propose that we cut a release here. >> > >> > (8) After we cut the release, we can introduce the work for ES >> 5.x in >> > METRON-939. I know we will need lots of help testing and reviewing >> this >> > one. >> > >> > Please correct me if I am wrong. I will try and send out updates >> as we >> > make progress. >> > >> > >> > >> > >> > >> > On Mon, Nov 6, 2017 at 1:03 PM, zeo...@gmail.com <zeo...@gmail.com> >> wrote: >> > >> > > I agree, I think it's very reasonable to move in line with Nick's >> > > proposal. I would also suggest that we outline what the target >> versions >> > > would be to add in the METRON-777 components, since it has been >> > functional >> > > for a very long time but not reviewed and has some really rockstar >> > > improvements. >> > > >> > > Jon >> > > >> > > On Mon, Nov 6, 2017 at 12:56 PM Otto Fowler < >> ottobackwa...@gmail.com> >> > > wrote: >> > > >> > > > I think the ES cutover should be the start of the 0.5.x series, >> and we >> > > > continue on with 0.4.x for the >> > > > metadata improvements etc. We could chose to focus 0.5.x’s >> first >> > > releases >> > > > on not only ES but >> > > > getting a handle on kibana and the mpack situation as well. >> > > > >> > > > >> > > > >> > > > >> > > > On November 6, 2017 at 12:48:45, Michael Miklavcic ( >> > > > michael.miklav...@gmail.com) wrote: >> > > > >> > > > I agree with your proposal, Nick. I think having a stabilizing >> release >> > > > prior to upgrading ES/Kibana makes sense. >> > > > >> > > > On Mon, Nov 6, 2017 at 9:16 AM, Nick Allen <n...@nickallen.org> >> wrote: >> > > > >> > > > > I would like to start a discussion around upcoming releases. >> We have >> > a >> > > > > couple separate significant tracks of work that we need to >> reconcile >> > in >> > > > our >> > > > > release schedule. >> > > > > >> > > > > (1) We have had (and have in review) a good number of bug >> fixes >> > > required >> > > > to >> > > > > support Metaalerts on the existing Elasticsearch 2.x >> infrastructure. >> > > > > >> > > > > >> > > > > (2) We also have ongoing work to upgrade our infrastructure to >> > > > > Elasticsearch 5.x, which will not be backwards compatible. >> > > > > >> > > > > >> > > > > I would like to see a release that has our best work on ES >> 2.x before >> > > we >> > > > > migrate to 5.x. I would propose the following. >> > > > > >> > > > > Release N+1: Introduce Metaalerts running on ES 2.x >> > > > > >> > > > > Release N+2: Cut-over to ES 5.x >> > > > > >> > > > > >> > > > > (Q) Is it worth cutting a separate release for ES 2.x? Is >> there a >> > > better >> > > > > way to handle the cut-over to 5.x? >> > > > > >> > > > >> > > -- >> > > >> > > Jon >> > > >> > >> >> >> >> -- > > Jon > -- Jon
