e.org" <dev@metron.apache.org>
> Cc: Matt Foley <mfo...@hortonworks.com>
> Subject: Re: [DISCUSS] Upcoming Release
>
> That script seems great, nick! Perhaps we should adjust the wiki around
> releases to point to it? Thoughts?
>
> On Fri, Dec 15, 2017 at 1:47 P
directory for
> “release_utils”.
>
> From: Casey Stella <ceste...@gmail.com>
> Date: Friday, December 15, 2017 at 10:50 AM
> To: "dev@metron.apache.org" <dev@metron.apache.org>
> Cc: Matt Foley <mfo...@hortonworks.com>
> Subject: Re: [DISCUSS] Upcoming Release
&g
ev@metron.apache.org>
> Cc: Matt Foley <mfo...@hortonworks.com>
> Subject: Re: [DISCUSS] Upcoming Release
>
> That script seems great, nick! Perhaps we should adjust the wiki around
> releases to point to it? Thoughts?
>
> On Fri, Dec 15, 2017 at 1:47 PM, Nick Allen <n...@nick
Perhaps under “build_utils” we should add a subdirectory for “release_utils”.
From: Casey Stella <ceste...@gmail.com>
Date: Friday, December 15, 2017 at 10:50 AM
To: "dev@metron.apache.org" <dev@metron.apache.org>
Cc: Matt Foley <mfo...@hortonworks.com>
Subject: Re
dix doc to
> the
> > Release Process documentation. I’ll do that.
> > Cheers,
> > --Matt
> >
> >
> > On 12/15/17, 9:15 AM, "Nick Allen" <n...@nickallen.org> wrote:
> >
> > Hi Matt -
> >
> > I just updated like 15+ JIRAs
>
> > On 12/12/17, 5:14 AM, "Nick Allen" <n...@nickallen.org> wrote:
> >
> > RC1 is looking good to me. I validated the MD5s, built Metron,
> built
> > the
> > Bro plugin and reviewed the other artifacts li
let’s see if anyone else find other issues.
>> >
>> >
>> >
>> > From: Otto Fowler <ottobackwa...@gmail.com>
>> > Date: Saturday, December 9, 2017 at 6:16 AM
>> > To: Matt Foley <mfo...@hortonworks.com>, "dev@m
t; >
> > From: Otto Fowler <ottobackwa...@gmail.com>
> > Date: Saturday, December 9, 2017 at 6:16 AM
> > To: Matt Foley <mfo...@hortonworks.com>, "dev@metron.apache.org" <
> > dev@metron.apache.org>
> Date: Saturday, December 9, 2017 at 6:16 AM
> > To: Matt Foley <mfo...@hortonworks.com>, "dev@metron.apache.org" <
> > dev@metron.apache.org>
> > Subject: Re: [DISCUSS] Upcoming Release
> >
> >
> >
> > So
gt; From: Otto Fowler <ottobackwa...@gmail.com>
> > Date: Saturday, December 9, 2017 at 6:16 AM
> > To: Matt Foley <mfo...@hortonworks.com>, "dev@metron.apache.org" <
> > dev@metron.apache.org>
> > Subject: Re: [DISCUSS] Upcoming Release
&
ey <mfo...@hortonworks.com>, "dev@metron.apache.org" <
> dev@metron.apache.org>
> Subject: Re: [DISCUSS] Upcoming Release
>
>
>
> So RC2 then?
>
>
>
> On December 8, 2017 at 20:43:21, Matt Foley (mfo...@hortonworks.com)
> wrote:
>
> Hah, here
Yes, but let’s see if anyone else find other issues.
From: Otto Fowler <ottobackwa...@gmail.com>
Date: Saturday, December 9, 2017 at 6:16 AM
To: Matt Foley <mfo...@hortonworks.com>, "dev@metron.apache.org"
<dev@metron.apache.org>
Subject: Re: [DISCUSS]
So RC2 then?
On December 8, 2017 at 20:43:21, Matt Foley (mfo...@hortonworks.com) wrote:
Hah, here it is: https://github.com/apache/metron/pull/743
“This problem seems to only reproduce when one unrolls a tarball rather
than cloning from github.”
Heh, the exclusion at
Hah, here it is: https://github.com/apache/metron/pull/743
“This problem seems to only reproduce when one unrolls a tarball rather than
cloning from github.”
Heh, the exclusion at https://github.com/apache/metron/blob/master/pom.xml#L351
is still there, but the hashcode in the bundle.css file
I remember having trouble with this bundle.css file on the last release, but I
can’t remember what we did about it. Anybody?
On 12/8/17, 1:41 PM, "Otto Fowler" wrote:
Steps
- Downloaded tar.gz’s, asc files and KEYS
- Verified signing of both
Steps
- Downloaded tar.gz’s, asc files and KEYS
- Verified signing of both tar.gz’s
- searched for rouge 0.4.1 entries
- verified the main pom.xml
- built :
mvn clean && time mvn -q -T 2C -DskipTests install && time mvn -q -T
2C surefire:test@unit-tests && time mvn -q
I poked around the RC briefly and spun up full dev with and without
sensors, no issues so far.
Jon
On Fri, Dec 8, 2017 at 4:34 AM Matt Foley wrote:
> Colleagues,
> I’ve posted Metron-0.4.2-RC1 and Metron-bro-plugin-kafka-0.1 to
>
Colleagues,
I’ve posted Metron-0.4.2-RC1 and Metron-bro-plugin-kafka-0.1 to
https://dist.apache.org/repos/dist/dev/metron/0.4.2-RC1/
Given the complexity of this RC, I’d appreciate if a couple people would be
willing to kick the tires before we put it up for a vote.
I will myself be going thru
Can we resolve the conversation regarding the second repo? I was waiting
to get more input/preferences from people There's also a documentation
update that fixes a few broken Stellar docs that already has aa +1, I just
need to merge it.
Jon
On Mon, Dec 4, 2017, 17:01 Casey Stella
I would be in favor of a release at this point.
On Mon, Dec 4, 2017 at 4:57 PM, Matt Foley wrote:
> Hey all,
> I see METRON-1252 was resolved over the weekend. Shall I go ahead and
> start the process with 0.4.2 release?
> Does anyone have any commits they feel strongly
Hey all,
I see METRON-1252 was resolved over the weekend. Shall I go ahead and start
the process with 0.4.2 release?
Does anyone have any commits they feel strongly should go in before 0.4.2 is
done, or are we ready to call it good?
I believe there is consensus the 0.4.2 release should
Considering the problems we are having with people building the node stuff
on centos, would it make sense to wait to take
a potential PR that allows full metron builds in our ansible docker image?
On November 26, 2017 at 21:26:27, Matt Foley (ma...@apache.org) wrote:
Hope everyone (at least
Hope everyone (at least in the U.S.) had a great Thanksgiving holiday.
Regarding status of the release effort, still pending METRON-1252, so not
making the release branch yet.
Regards,
--Matt
On 11/17/17, 1:32 PM, "Matt Foley" wrote:
(With release manager hat on)
Should we consider drafting some bare metal install instructions for 0.4.2
that can be a part of the release? Similar to
https://github.com/apache/metron/tree/master/metron-deployment/other-examples/manual-install
Or do we want to continue to have those instructions outside of the
releases
Makes sense now. Thanks Matt.
> On Nov 17, 2017, at 4:25 PM, Matt Foley wrote:
>
> Hi Ryan,
> Yes and no. The last release (see
> https://dist.apache.org/repos/dist/release/metron/ ) was 0.4.1, announced on
> 9/19.
> Immediately after that we bumped the of builds
Hi Ryan,
Yes and no. The last release (see
https://dist.apache.org/repos/dist/release/metron/ ) was 0.4.1, announced on
9/19.
Immediately after that we bumped the of builds from master branch,
per https://issues.apache.org/jira/browse/METRON-1196 . This is consistent
with the Release
Our last release was 0.4.1, so the next would be at least 0.4.2. We
recently have been keeping master at the next presumed release version.
On Fri, Nov 17, 2017 at 4:59 PM, Ryan Merriman wrote:
> Matt,
>
> I think we are currently on version 0.4.2. If that is the case
Matt,
I think we are currently on version 0.4.2. If that is the case would the
next version be 0.4.3?
Ryan
On Fri, Nov 17, 2017 at 3:31 PM, Matt Foley wrote:
> (With release manager hat on)
>
> The community has proposed a release of Metron in the near future,
> focusing on
(With release manager hat on)
The community has proposed a release of Metron in the near future, focusing on
Meta-alerts running in Elasticsearch.
Congrats on getting so many of the below already done. At this point, only
METRON-1252, and the discussion of how to handle joint release of the
I just wanted to send an update on where we are at. We've gotten a lot
done here recently as you can see below.
✓ DONE (1) First, METRON-1289 needs to go in. This one was a fairly big
effort and I am hearing that we are pretty close.
✓ DONE (2) METRON-1294 fixes an issue in how field types
Sorry, missed one. I think this is the one Jon prefers.
(5) The other alternative is just to complete Jon's roadmap BEFORE the next
release.
On Thu, Nov 16, 2017 at 10:37 AM, Nick Allen wrote:
> Just to layout some other alternatives...
>
> (1) [Jon] Make a release in
> (1) [Jon] Make a release in apache/metron-bro-plugin-kafka, then update
Ansible to pin to that release.
The problem with this approach, as I see it, is that it commits us to
having separate releases for the Bro plugin. Which I am not sure if or how
long it will take to come to a consensus on
Just to layout some other alternatives...
(1) [Jon] Make a release in apache/metron-bro-plugin-kafka, then update
Ansible to pin to that release.
(2) [Jon] Update Ansible to pin to a specific commit.
(3) Wouldn't the submodule approach solve this? I imagine that if we use a
submodule, then all
The problem is that we're currently pinning to master and if something in
the plugin breaks backward compatibility, our prior releases will be
perpetually broken, which is why I suggest it blocks the upcoming release.
The alternative would be to update ansible to pin to a specific commit or
to
While I think that the Bro work is super valuable, Jon, I am not sure that
we need to block the next release for it. In my mind, the "theme" of the
next release is Metaalerts running on ES 2.x. I'd prefer to just stick
with that.
I was hoping we could get the remaining "Metaalerts + ES 2.x" PRs
My PR is to turn it into a package containing a plugin*
On Thu, Nov 16, 2017, 08:01 zeo...@gmail.com wrote:
> The way master's full-dev is set up right now is non optimal for the bro
> plugin configuration, and I would like to complete the roadmap I outlined
> in my discuss
The way master's full-dev is set up right now is non optimal for the bro
plugin configuration, and I would like to complete the roadmap I outlined
in my discuss thread before a release. I have a PR open against
Apache/metron-bro-plugin-kafka right now to turn it into a plugin, and I
expect it
I’ve been listening. Looks like there are still a number of major issues to be
committed first, right?
The discussion on this thread constitutes sufficient engagement, I think,
especially given the Subject line :-)
Would the folks working on the 6 issues listed by Nick care to suggest a
I'd say that if a release is this imminent that we had better notify the
release manager who will make a release announcement, Nick. Matt, are you
tuning in to this?
On Wed, Nov 15, 2017 at 10:04 AM, Nick Allen wrote:
> Hi Guys -
>
> I want to follow-up on this discussion.
When I speak of the mpack situation, I’m speaking of the discussion around
removing them.
On November 6, 2017 at 15:14:59, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:
Kibana and MPack are currently being handled as part of the ES upgrade. I'm
recreating the Kibana dashboards right
Kibana and MPack are currently being handled as part of the ES upgrade. I'm
recreating the Kibana dashboards right now. Long story short, there was an
issue upgrading from our pickle file, so I'm recreating it from scratch and
will attempt an alternative approach to storing the dashboard
I agree, I think it's very reasonable to move in line with Nick's
proposal. I would also suggest that we outline what the target versions
would be to add in the METRON-777 components, since it has been functional
for a very long time but not reviewed and has some really rockstar
improvements.
I think the ES cutover should be the start of the 0.5.x series, and we
continue on with 0.4.x for the
metadata improvements etc. We could chose to focus 0.5.x’s first releases
on not only ES but
getting a handle on kibana and the mpack situation as well.
On November 6, 2017 at 12:48:45,
I agree with your proposal, Nick. I think having a stabilizing release
prior to upgrading ES/Kibana makes sense.
On Mon, Nov 6, 2017 at 9:16 AM, Nick Allen wrote:
> I would like to start a discussion around upcoming releases. We have a
> couple separate significant tracks
44 matches
Mail list logo