Re: [DISCUSS] Split Elasticsearch and Kibana into separate MPack from Metron

2018-02-21 Thread David Lyle
Hi Mike, I agree. Def +1 on the first approach. Keep it with the Metron version. -D... On Wed, Feb 21, 2018 at 11:30 AM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Anyone have any opinions on how we should version the ES/Kibana MPack? > > We currently rev the Metron one based

Re: [DISCUSS] Split Elasticsearch and Kibana into separate MPack from Metron

2018-02-21 Thread zeo...@gmail.com
I agree, the first approach makes the most sense to me. Jon On Wed, Feb 21, 2018 at 11:45 AM Nick Allen wrote: > +1 to the first approach, as you've laid it out. That makes the most sense > to me. We need a way to rev the version of the ES Mpack independent of the > ES

Re: [DISCUSS] Split Elasticsearch and Kibana into separate MPack from Metron

2018-02-21 Thread Nick Allen
+1 to the first approach, as you've laid it out. That makes the most sense to me. We need a way to rev the version of the ES Mpack independent of the ES version. On Wed, Feb 21, 2018 at 11:30 AM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Anyone have any opinions on how we

Re: [DISCUSS] Split Elasticsearch and Kibana into separate MPack from Metron

2018-02-21 Thread Michael Miklavcic
Anyone have any opinions on how we should version the ES/Kibana MPack? We currently rev the Metron one based on current Metron version and apply it to both the overall MPack as well as the individual service versions, e.g. metron_mpack-0.4.3.0/common-services/METRON/0.4.3. For ES we have been

Re: [DISCUSS] Split Elasticsearch and Kibana into separate MPack from Metron

2018-02-17 Thread Nick Allen
+1 I agree with Otto's idea. It makes a lot of sense for Elasticsearch and Kibana to live in a separate Mpack. This provides us a path forward to support additional indexers like Solr. We should also not force our users to install an external component (like Elasticsearch) using the Mpack.