Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142236713
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -35,7 +36,7 @@
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142237205
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -35,7 +36,7 @@
Github user dbist commented on the issue:
https://github.com/apache/metron/pull/664
I have a failure locally, will re-do the commit.
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/737
I moved the default values to the storm config and changed getNumWorkers
and getNumAckers to return the values in the storm config if
numWorkers/numAckers is null. Is this what you were thinking?
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/664
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/782
Please fill out the PR description
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/772
Oh, sorry, forgot to respond here @ottobackwards You can test it by passing
in a log4j properties (let's say something that turns on DEBUG logging) file
via -l and ensure that the REPL shows debug
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142149285
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -45,4 +45,14 @@ private
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142149083
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -45,4 +45,14 @@ private
Github user cestella commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142147088
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -45,4 +45,14 @@ private HttpStatus
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/732
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/771
+1 by inspection, great job @merrimanr
---
Ok, the build is broken in metron-config due to some transitive changes
that happened in npm-land:
[INFO]
/Users/cstella/Documents/workspace/metron/fork/incubator-metron/metron-interface/metron-config/node_modules/toposort/index.js:32
[INFO] throw new Error('Cyclic dependency:
[WARNING] npm WARN deprecated bower@1.8.2: ...psst! Your project can stop
working at any moment because its dependencies can change. Prevent this by
migrating to Yarn:
https://bower.io/blog/2017/how-to-migrate-away-from-bower/
On October 2, 2017 at 11:29:50, Casey Stella (ceste...@gmail.com)
Maybe we added a dependency or something since?
On October 2, 2017 at 11:04:16, zeo...@gmail.com (zeo...@gmail.com) wrote:
Hmm, 0.4.1 built fine for me.
Jon
On Mon, Oct 2, 2017 at 10:44 AM Casey Stella wrote:
> Ok, the build is broken in metron-config due to some
I can confirm 0.4.1 (on CentOS 6!) builds for me as well.
Are we sure it isn't due to the version of node shipped with the OS?
On 2017-10-02 08:04, zeo...@gmail.com wrote:
Hmm, 0.4.1 built fine for me.
Jon
On Mon, Oct 2, 2017 at 10:44 AM Casey Stella
wrote:
Ok, the
1. My failing builds are working again, both my branch off of master and
my pr checkouts, all that was required was a mvn clean package
2. There was some discussion on yarn recently in a pr, though I can’t
remember which one
On October 2, 2017 at 11:45:48, Casey Stella (ceste...@gmail.com)
Hmm, 0.4.1 built fine for me.
Jon
On Mon, Oct 2, 2017 at 10:44 AM Casey Stella wrote:
> Ok, the build is broken in metron-config due to some transitive changes
> that happened in npm-land:
>
> [INFO]
>
>
We download and install node locally. But you can test this by :
> git fetch apache
> git checkout -b build-test apache/master
> mvn clean package -DskipTests
On October 2, 2017 at 11:17:03, Laurens Vets (laur...@daemon.be) wrote:
I can confirm 0.4.1 (on CentOS 6!) builds for me as well.
Yeah, seems like it might be worth while to seriously investigate migrating
to yarn if that gets us a consistent build.
On Mon, Oct 2, 2017 at 11:37 AM, Otto Fowler
wrote:
> [WARNING] npm WARN deprecated bower@1.8.2: ...psst! Your project can stop
> working at any
http://mail-archives.apache.org/mod_mbox/metron-dev/201708.mbox/%3cCAGh_R=xvLB3tg_j3FhupyMz4iUsiXmNbagHKZ=gtfdc8u4b...@mail.gmail.com%3e
On October 2, 2017 at 11:50:48, Otto Fowler (ottobackwa...@gmail.com) wrote:
1. My failing builds are working again, both my branch off of master and
my pr
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/780#discussion_r142215715
--- Diff: metron-platform/metron-indexing/README.md ---
@@ -163,6 +163,36 @@ Both of these functions are handled under the hood.
In addition, an API
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/780
> Honestly, I think it should at the very least be linked from the
documentation which tells people how to create their own parsers...which we do
not seem to have. ;)
Yes @cestella, I
> Maybe change the text on the button on the primary panel to "write"
instead of "save"?
Another option would be to call it "Apply".
> Also, I want wider child panels in the management UI if at all possible.
> Especially
the "RAW JSON" feels cramped.
Yes, I agree. It seems to odd to me that
I think the main reason historically is that each UI has different use
cases and user roles. The Management UI will mainly be used by an Security
Platform Engineer, while the Alerts UI will be used by a SOC Analyst,
Investigator or Manager.
That being said, I am not against a single, unified UI,
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/772
+1
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/772
As a note :
```bash
-> % mvn exec:java \
-Dexec.mainClass="org.apache.metron.stellar.common.shell.StellarShell"
-Dexec.args="-l src/test/resources/log4j.properties"
Maybe we should use DEPLOY as the final stage?
On October 2, 2017 at 14:31:08, Nick Allen (n...@nickallen.org) wrote:
> Maybe change the text on the button on the primary panel to "write"
instead of "save"?
Another option would be to call it "Apply".
> Also, I want wider child panels in the
I might have spoken too soon. This is what I see now on 0.4.1-release:
...
[INFO] metron-contrib . SUCCESS [
0.006 s]
[INFO] metron-docker .. SUCCESS [
3.088 s]
[INFO] metron-interface ...
Well, that's a prescient and didn't seem to get any love.
On Mon, Oct 2, 2017 at 11:53 AM, Otto Fowler
wrote:
> http://mail-archives.apache.org/mod_mbox/metron-dev/
> 201708.mbox/%3cCAGh_R=xvLB3tg_j3FhupyMz4iUsiXmNbagHKZ=
> gtfdc8u4b...@mail.gmail.com%3e
>
>
> On
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/737
So, I do believe the default values for num workers and ackers should be
taken from the storm config if unspecified by us. Providing defaults when
storm already has defaults for these properties
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/780
> Where should this live? I have this put up, so people can see what it
says, but I'm pretty sure it should live somewhere else, under a different
heading. I'm just not sure what the best
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/780
Honestly, I think it should at the very least be linked from the
documentation which tells people how to create their own parsers...which we do
not seem to have. ;)
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/780
Also, should be linked from metron-parsers makes sense IMO as any time you
are adding a new sensor, you're going to need to add this field. This is the
use-case that keeps biting us in the butt
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/772
Does this change the default log level of the REPL when run in a deployed
Metron cluster?
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/772
It does not and should not. If that's what you're seeing, @nickwallen
then it's a bug and I should fix it.
---
Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/779
The latest commit replaces the getFullMessage call with
ExceptionUtils.getStackTrace. Hopefully that addresses the recursion issue.
As for security @ottobackwards, I'm not sure what the
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/771
---
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/779#discussion_r142235450
--- Diff:
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/controller/RestExceptionHandler.java
---
@@ -35,7 +36,7 @@
39 matches
Mail list logo