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
> >
>
