metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zeolla@GMail.com" <zeo...@gmail.com>
Subject Re: [DISCUSS] Upcoming Release
Date Thu, 16 Nov 2017 13:01:07 GMT
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 <mattf@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" <cestella@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 <nick@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, Zeolla@GMail.com <zeolla@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 <
> ottobackwards@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.miklavcic@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 <nick@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

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