Hi All,
I am trying to investigate whether we can disable a Metron parser output
writer entirely and manage it via KAFKA_PUT Stellar function instead.
First, is it possible via configuration? Second, will be any performance
difference between normal Kafka writer and the Stellar version of it
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/922#discussion_r165548937
--- Diff:
metron-platform/metron-solr/src/test/java/org/apache/metron/solr/schema/SchemaTranslatorTest.java
---
@@ -0,0 +1,188 @@
+/**
+ *
Github user ottobackwards commented on a diff in the pull request:
https://github.com/apache/metron/pull/922#discussion_r165548986
--- Diff:
metron-platform/metron-solr/src/test/java/org/apache/metron/solr/schema/SchemaTranslatorTest.java
---
@@ -0,0 +1,188 @@
+/**
+ *
Personally, I'd be in favor of something like Maria DB as an open source
repo. Or any other ansi sql store. On the positive side, it should mesh
seamlessly with ORM tools. And the schema for this should be pretty
vanilla, I'd imagine. I might even consider skipping ORM for straight JDBC
and simple
Github user merrimanr closed the pull request at:
https://github.com/apache/metron/pull/911
---
So, I'll answer your question with some questions:
- No matter the data store we use upgrading will take some care, right?
- Do we currently depend on a RDBMS anywhere? I want to say that we do
in the REST layer already, right?
- If we don't use a RDBMs, what's the other option?
Github user cestella closed the pull request at:
https://github.com/apache/metron/pull/921
---
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/922
METRON-1441: Create complementary Solr schemas for the main sensors
## Contributor Comments
We have ES templates for bro, snort, yaf, and error, we need corresponding
solr schemas for these
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/911
actually, it may be that feature branch PRs don't automatically close..or
hmm, not sure. Anyway, close it please :)
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/911
well, I botched the stupid commit message and put `apache/metron` when I
meant `apache/feature/METRON-1416-upgrade-solr`. Can you close this PR
@merrimanr ?
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/921
I know that commit history looks pretty awful, but it's because I branched
off of @merrimanr 's SolrDao PR initially. Now that PR is in the branch, so
the comparison should be more sensible.
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/918
I got full dev spinning spun up with this, and it looks good. I think the
latest couple comments are still to be addressed, but otherwise good to go.
---
GitHub user cestella opened a pull request:
https://github.com/apache/metron/pull/921
METRON-1441: Create complementary Solr schemas for the main sensors
## Contributor Comments
We have ES templates for bro, snort, yaf, and error, we need corresponding
solr schemas for these
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/911
I looked over the changes and refactor. Thanks a lot for taking care of
that, it looks a lot better and is definitely easier to grok, imo, than the old
way.
I'm +1 on merging this into
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/919
---
GitHub user ottobackwards opened a pull request:
https://github.com/apache/metron/pull/920
METRON-1438 Move SHELL functions from metron-management to stellar-common
Part of making stellar more modular and stand alone is consolidation of
stellar functionality scattered through
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/919
No, I am sorry, I thought that was understood. I have not reviewed, but I
would go ahead based on @cestella
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/919
@ottobackwards Any objections to having the discussion outside of this and
merging this in as-is?
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/919
so, I'm +1 on this and we probably want a discussion outside of this about
where to move `platform-info.sh`
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/919
this is a user utility though, not a dev one. I would create a new
support-scripts folder
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/919
> Sidenote, do we want to move this script to the dev-utilities dir?
I do think it would be good to move that script. Not sure where under
dev-utilities though. And we can tackle as
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/919
+1 works great for me. Thanks
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/919
Sidenote, do we want to move this script to the dev-utilities dir?
---
GitHub user justinleet opened a pull request:
https://github.com/apache/metron/pull/919
METRON-1439: Turn off git pager in platform-info script
## Contributor Comments
Just added a couple --no-pager args. Before you'd have to progress past
the couple git pages, now they should
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/917
+1 by inspection, great work!
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/579
@ctramnitz thank you! Let us know where you are at and if we can help
---
Github user ctramnitz commented on the issue:
https://github.com/apache/metron/pull/579
Rebasing to master to see where we are. If this comes back clean please
don't merge yet, I want to add 8.0 log format first.
---
There is currently a PR up for review that allows a user to configure and
save the list of facet fields that appear in the left column of the Alerts
UI: https://github.com/apache/metron/pull/853. The REST layer has ORM
support which means we can store those in a relational database.
However I'm
Github user JonZeolla commented on the issue:
https://github.com/apache/metron/pull/865
Ping
---
Github user mraliagha commented on the issue:
https://github.com/apache/metron/pull/915
@cestella Definitely there will be value for having an ability to turn it
on and off especially since you have already implemented that. However, won't
be a sort of premature disk optimization? We
30 matches
Mail list logo
