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 keeping the service version matched to the current ES version because it's independent of Metron, ie 5.6.2. The upshot is that we can handle this one of two ways.
1. Keep the same approach after splitting off ES and Kibana - ES MPack version is set to the current Metron version (0.4.3) and the service itself is set to the ES version (5.6.2). 2. Use ES version for both the MPack version and service version (5.6.2). I personally recommend and prefer the first approach because it allows us to make changes to the mpack itself without necessarily changing the version of ES or Kibana, which is something that is likely to happen. It's also consistent and seamless with our current versioning approach. Lastly, I don't believe the ES versions provide much contextual sense in the Metron world for an MPack version - setting the service version definitely makes sense to indicate what exact ES version we're using, but the MPack is really our way of providing custom functionality that wraps a specific version of ES/Kibana. Hope this makes sense. Mike On Sat, Feb 17, 2018 at 11:13 AM, Nick Allen <n...@nickallen.org> wrote: > +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. There are just too many installation > configurations for us to reasonably support; especially on larger > installations. Supporting the Elasticsearch MPack is a project unto > itself. That being said, the functionality will still be there for those > that want to use it. > > > > On Fri, Feb 16, 2018 at 4:10 PM, Michael Miklavcic < > michael.miklav...@gmail.com> wrote: > > > This came up earlier when discussing work around the ES upgrade: > > https://lists.apache.org/thread.html/66280bc061afbba2c353221c3c05fd > > 74b247b970921c009c29edc815@%3Cdev.metron.apache.org%3E > > https://lists.apache.org/thread.html/8ec83b6a3ef39057c9466ff72a2f63 > > c9308452f1ebc1804e67cb495b@%3Cdev.metron.apache.org%3E > > > > Looks like Otto made this suggestion and Kyle is on board. I was > originally > > opposed to this because it did not seem worth the effort to support 2 > > separate MPacks. However, now that we are working on the Solr upgrade, it > > seems like an appropriate solution for enabling us to make the indexing > > piece pluggable. I propose that we commence with this solution. > > > > Cheers, > > Mike > > >
