metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject [DISCUSS] Merging Solr feature branch (METRON-1416) into master
Date Thu, 21 Jun 2018 17:20:56 GMT
Hi All,

The Solr branch (/feature/METRON-1416-upgrade-solr
<https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr>),
has been progressing for a while now.  I'd like to open up discussion
around what it takes to get it into master.

The JIRA for tracking this feature branch is METRON-1416
<https://issues.apache.org/jira/browse/METRON-1416>.

As shown in the JIRA, the majority of tasks are complete, with a few
outstanding issues. Of these, I believe these are the main ones of interest
to this discussion.

   - METRON-1629 <https://issues.apache.org/jira/browse/METRON-1629> -
   There is an active PR #1072 <https://github.com/apache/metron/pull/1072>
   - METRON-1609 <https://issues.apache.org/jira/browse/METRON-1609> -
   There is an active PR #1056 <https://github.com/apache/metron/pull/1056>
   - METRON-1602 <https://issues.apache.org/jira/browse/METRON-1602> - Full
   dev can run with Solr without this, it would simply be more convenient.
   - METRON-1632 <https://issues.apache.org/jira/browse/METRON-1632> -
   Causes a metaalert specific issue where UI filtering on
   source.type:metaalert fails. More detail is on the Jira.
   - Two validation tickets.  It's been run up on multinode, and manual
   testing has happened (and I'm will be seen a bit more on the final PR by
   various reviewers), so I'm inclined to just leave these open until we're
   good to go.  Let me know if we want to handle this differently.

I'm of the opinion both of the active PRs need to be merged before we merge
this into master, especially the documentation one.  The other two tickets
can be done in the future; one can be worked around and one is a metaalert
specific issue that primarily effects the alerts UI.

As the branch has grown and diverged from master, it's gotten increasingly
unwieldy to maintain (and I think it's worth a follow-on discussion about
how we manage refactorings that happen in these sorts of branches).  I know
there's been at least a couple merges from master that have been
nontrivially difficult and required careful testing, particularly around
the DAO layer, to avoid regressions in both code and tests.

The feature set is pretty complete.  The UI works, barring the metaalert
issue.  Much of the backend has been refactored and seen improved test
coverage benefiting both Solr and Elasticsearch.  The main difference
between ES and Solr is the lack of the equivalent visualizations to
Kibana.  I don't believe the feature branch needs to wait for this, as it's
pretty standalone work that can be added as usage and demand dictates.

I'm of the opinion that the benefits of getting the branch into master
outweighs the issues still present, especially in terms of making
refactoring and features available and easing the dev burden.  The
remaining tickets are Solr specific, and ES functions as it does in master.

Are there any must-haves before we bring this branch back?  Are there any
other concerns we have before a final PR is opened (pending completion of
active PRs and any other must-haves)?

Justin

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message