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 <ma...@apache.org> 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 of > 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 to > deployment tools (docker, ansible, mpack, quickdev, and fulldev). > > I think the REST API and Kerberization, by themselves, would justify a > release. Along with the others, I’d like to propose that we make a 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) and 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? The > 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 > > >
