When I speak of the mpack situation, I’m speaking of the discussion around removing them.
On November 6, 2017 at 15:14:59, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: Kibana and MPack are currently being handled as part of the ES upgrade. I'm recreating the Kibana dashboards right now. Long story short, there was an issue upgrading from our pickle file, so I'm recreating it from scratch and will attempt an alternative approach to storing the dashboard templates. On Mon, Nov 6, 2017 at 10:56 AM, 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? > > > >
