metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <>
Subject Re: [DISCUSS] next release proposal
Date Thu, 20 Apr 2017 06:13:38 GMT
Hi all,
I’ve put together RC1 for the 0.4.0 release of Metron, along with its book-site.  It is
available for your review at 

I’m not putting it to VOTE yet, because I think some additional fixes are probably necessary:
• We should add documentation for the remaining backward-incompatible changes
• We should add these important bug fixes that have been committed to master since the 0.4.0
branch was cut:
    o METRON-634 fixes for Mpack for Centos7
    o METRON-856 Ansible rpm build wipes out prior binary build
    o METRON-821 Minor fixes in full dev kerberos setup instructions
    o Please give me your +1 for these additions
• These PRs are currently open, and seem important to complete the Kerberos picture:
    o METRON-799: The MPack should function in a kerberized cluster 
    o METRON-835 Use Profiler with Kerberos 
    o METRON-836 Use Pycapa with Kerberos
    o METRON-859 Use REST application with Kerberos
    o Please give me your evaluation of whether these can be committed Real Soon Now, or we
should not wait for them.
• This PR is open and seems important to complete the REST picture:
    o METRON-795: Install Metron REST with Ambari MPack
    o Please give me your evaluation of whether this can be committed Real Soon Now, or we
should not wait for it.
• Anything else?  I’ve deliberately left out the commits on master that represent new
functionality not already in (or mostly in) the 0.4.0 branch.


On 4/18/17, 5:30 PM, "Matt Foley" <> wrote:

    Thanks, we’re now up to 4 backward-incompatible issues.  Any others should be so marked?
    On 4/17/17, 4:43 PM, "Matt Foley" <> wrote:
        Hi all,
        Out of the 58 Jiras resolved, completely or partially, between 0.3.1 and 0.4.0, only
one is labeled “backward-incompatible” and has text in the “Docs Text” field.  And
it’s super minor (METRON-771).
        Is this really true?  If so, great, but if not, please help people upgrade without
glitches:  Fix these fields in your jiras, so they can be included in the Release Notes.
        a) In the “Labels” field, add “backward-incompatible”.  (It will autocomplete
for you.)
        b) In the “Doc Text” field, say what the issue is and what a person upgrading
should do about it, if anything.
        As usual, non-response will be considered positive confirmation that no response is
necessary :-)
        Please try to address in the next day or so.
        Your humble Release Manager
        On 4/12/17, 10:59 AM, "" <> wrote:
            I agree conceptually but haven't looked at them each individually to see
            how much they impact and if a short timeline for merging is reasonable.
            METRON-821 just needs a minor change and then a final run-through before
            I'm comfortable merging it in.
            On Wed, Apr 12, 2017 at 11:44 AM Nick Allen <> wrote:
            > It would be nice to close out all the "Kerberos" related PRs prior to the
            > release.  Let me know if anyone thinks any of these are not feasible for
            > the release.
            > To that end I went through and reviewed some of the outstanding ones below
            > to try and help move them along.  Any others willing to help would be much
            > appreciated.
            > METRON-836 Use Pycapa with Kerberos
            > #524 opened 18 hours ago by nickwallen
            > METRON-835 Use Profiler with Kerberos
            > #521 opened 2 days ago by nickwalle
            > METRON-833: Update MaaS documentation to explain how it interacts with
            > kerberos
            > #520 opened 5 days ago by cestella
            > METRON-799: The MPack should function in a kerberized cluster
            > #518 opened 5 days ago by justinlee
            > METRON-821 Minor fixes in full dev kerberos setup instructions
            > #510 opened 8 days ago by JonZeolla  4 of 4
            > METRON-819: Document kafka console producer parameter for sensors with
            > kerberos
            > #507 opened 9 days ago by mmiklavc  4 of 4
            > On Tue, Apr 4, 2017 at 2:09 PM, Matt Foley <> wrote:
            > > Hi all,
            > > Although it’s only been a few weeks since the last release was finally
            > > published, that process started in January :-)
            > > Also, the last commit in 0.3.1 was Feb 23, and there’s been a ton
            > > really cool new stuff added since then:
            > >
            > > Biggest items:
            > > - Multiple commits for REST API (base Jira: METRON-503)
            > > - Multiple commits to work with Kerberized (secure) clusters (mult.
            > Jiras)
            > >
            > > Other major new features:
            > > - METRON-690: DSL-based sparse time window specification for Profiler
            > > - METRON-733: Remove Geo db from ParserBolt
            > > - METRON-686: Record rule set that fired during Threat Triage
            > > - METRON-743: Sort files when reading results from Pcap
            > > - METRON-701: Triage metrics produced by Profiler
            > > - METRON-744: Stellar external functions loaded from HDFS (and huge
            > > speed-up for function resolution)
            > > - METRON-694: Index errors from Topologies, and
            > > - METRON-745: Create Error dashboards
            > > - METRON-712: Separate eval from parse in Stellar
            > > - METRON-765: Add GUID to messages
            > > - METRON-793: Updated to storm-kafka-client spout
            > >
            > > We’ve also had numerous bug fixes, docs improvements, and improvements
            > > deployment tools (docker, ansible, mpack, quickdev, and fulldev).
            > >
            > > I think the REST API and Kerberization, by themselves, would justify
            > > release.  Along with the others, I’d like to propose that we make
            > release
            > > soon.  The time frame I had in mind was at the end of this week I could
            > cut
            > > a release branch (so on-going work in master doesn’t get blocked)
            > start
            > > the process of generating an RC.
            > >
            > > What do you-all think?
            > > Also, what additional work do you think should be included in this
            > > release, and can it realistically get done by the end of this week?
            > > time frame is, of course, flexible at the pleasure of the community
– but
            > > also, there will be another release in another couple months or so,
so no
            > > need to rush stuff.
            > >
            > > Thanks,
            > > --Matt
            > >
            > >
            > >

View raw message