metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] Upcoming Release
Date Wed, 15 Nov 2017 15:04:54 GMT
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
>

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