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