[GitHub] metron issue #825: METRON-1290: Only first 10 alerts are update when a MetaA...

Github user justinleet commented on the issue: https://github.com/apache/metron/pull/825 @nickwallen I'm about to open a PR with an updated integration test. We should be able to close this one, since the changes here aren't relevant anymore. ---

Re: [DISCUSS] Upcoming Release

> (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

[GitHub] metron pull request #842: METRON-1290: Only first 10 alerts are update when ...

Github user asfgit closed the pull request at: https://github.com/apache/metron/pull/842 ---

Re: [DISCUSS] Upcoming Release

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

[GitHub] metron pull request #842: METRON-1290: Only first 10 alerts are update when ...

GitHub user justinleet opened a pull request: https://github.com/apache/metron/pull/842 METRON-1290: Only first 10 alerts are update when a MetaAlert status is changed to inactive ## Contributor Comments This PR supercedes https://github.com/apache/metron/pull/825. The fix was

[GitHub] metron issue #825: METRON-1290: Only first 10 alerts are update when a MetaA...

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/825 Sounds good. I will take a look at #842. ---

Re: [DISCUSS] Upcoming Release

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

Re: [MENTORS][DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

I expect a few version changes up front to add some new features to the package (0.1 for the initial release, 0.{2..n} for some new features, 1.0 when we stabilize) but after that it will probably only be updated to follow kafka/librdkafka updates. Jon On Thu, Nov 16, 2017 at 10:10 AM Otto

Re: [DISCUSS] Upcoming Release

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

[GitHub] metron pull request #826: METRON-1291: Kafka produce REST endpoint does not ...

Github user merrimanr commented on a diff in the pull request: https://github.com/apache/metron/pull/826#discussion_r151450858 --- Diff: metron-interface/metron-rest/src/main/java/org/apache/metron/rest/config/KafkaConfig.java --- @@ -108,6 +108,9 @@ public ZkUtils zkUtils() {

Re: [MENTORS][DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

How often to we expect to change this? If it is effectively pinned then a release process is not that bad. On November 16, 2017 at 10:06:53, Nick Allen (n...@nickallen.org) wrote: > > I would suggest that we institute a release procedure for the package > itself, but I don't think it

Re: [DISCUSS] Upcoming Release

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

[GitHub] metron issue #825: METRON-1290: Only first 10 alerts are update when a MetaA...

Github user justinleet commented on the issue: https://github.com/apache/metron/pull/825 @nickwallen https://github.com/apache/metron/pull/842 @merrimanr If you're good with that PR, feel free to close this one. ---

[GitHub] metron pull request #825: METRON-1290: Only first 10 alerts are update when ...

Github user merrimanr closed the pull request at: https://github.com/apache/metron/pull/825 ---

[GitHub] metron issue #841: METRON-1316 Fastcapa Fails to Compile in Test Environment

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/841 > During the deployment, I noticed the following message. I was not sure if this can be ignored or needs to be looked at. Hi Anand - Thanks for testing! I saw that a few times also.

[GitHub] metron pull request #839: METRON-1311 Service Check Should Check Elasticsear...

Github user asfgit closed the pull request at: https://github.com/apache/metron/pull/839 ---

[GitHub] metron issue #825: METRON-1290: Only first 10 alerts are update when a MetaA...

Github user justinleet commented on the issue: https://github.com/apache/metron/pull/825 @merrimanr This is already taken care of by the various refactoring in https://github.com/apache/metron/pull/824, right? Can you close this (and the associated jira) if that's accurate? ---

[GitHub] metron issue #832: METRON-1301 Sorting on Triage Score Unexpectedly Filters ...

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/832 I merged with the latest changed from #824 ---

Re: [DISCUSS] Upcoming Release

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

Re: [DISCUSS] Upcoming Release

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

[GitHub] metron issue #825: METRON-1290: Only first 10 alerts are update when a MetaA...

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/825 Even if the functionality is addressed, are there tests that cover this condition that we can pull in from this PR? I don't think we ever got a proper integration test to cover this issue, but

Re: [DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

I would suggest that we institute a release procedure for the package itself, but I don't think it necessarily has to line up with metron releases (happy to be persuaded otherwise). Then we can just link metron to metron-bro-plugin-kafka by pointing to specific metron-bro-plugin-kafka releases

Re: [DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

I'd recommend restarting this thread with this subject and including [MENTORS] in the subject line. At least I don't know the answer to this and I'd want broader visibility so we get more responses. On Thu, Nov 16, 2017 at 9:10 AM, Nick Allen wrote: > The code of the 'Kafka

[MENTORS][DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

+ Restarting the thread to include mentors. The code of the 'Kafka Plugin for Bro' is now maintained in the external repository that we set up a while back. - Metron Core: git://git.apache.org/metron.git - Kafka Plugin for Bro: git://git.apache.org/metron-bro-plugin-kafka.git (Q) Do we

[DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

The code of the 'Kafka Plugin for Bro' is now maintained in the external repository that we set up a while back. Do we need to change anything in the release procedure to account for this?

master full-dev issues?

Anybody else having issues spinning up full-dev? I'm consistently failing on the Metron Alerts UI install. Spun it up fine yesterday for my other testing. 2017-11-16 17:57:41,772 - Execution of '/usr/bin/yum -d 0 -e 0 -y install metron-common' returned 1. Error: Nothing to do

Re: [MENTORS][DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

There’s two issues, I think: (1) We’d like to be able to version and evolve the main body of Metron and the metron-bro-plugin-kafka separately. (2) We want to be able to assure that each release of Metron has a known-working version of metron-bro-plugin-kafka At a very simple level, we can

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/827 Even better then. Can we just get rid of it? ---

Re: [DISCUSS] Release Procedure + 'Kafka Plugin for Bro'

There’s two issues, I think: (1) We’d like to be able to version and evolve the main body of Metron and the metron-bro-plugin-kafka separately. (2) We want to be able to assure that each release of Metron has a known-working version of metron-bro-plugin-kafka At a very simple level, we can

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/827 Actually the more I think about it, I would not consider a field to be common between indices when the types mismatch. Hard to say what the right answer is because there is no real requirement

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/827 I don't think that method is even used anymore but I will add the mismatch handling just in case. ---

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/827 How does `getCommonColumnMetadata` behave when we have a mismatched field (aka a field named the same in two different indices, but with different types)? Do we need similar mismatch handling?

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/827 Was commenting while your comment posted. I think your latest suggestion is the right answer :) ---

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/827 The latest commit fixes the bug @justinleet found and adds some test cases to cover it. I also removed an "ignoredIndices" variable from the ElasticsearchDao class. This was being used

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user justinleet commented on the issue: https://github.com/apache/metron/pull/827 I tried hitting the `/api/v1/search/column/metadata` endpoint on fulldev with `["madeupindex"]`; e.g. curl -X POST --header 'Content-Type: application/json' --header 'Accept:

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user JonZeolla commented on the issue: https://github.com/apache/metron/pull/827 I didn't get myself intimately familiar with this PR, but I wanted to mention that assuming two fields with the same name but different types between indexes are not the same may not always hold.

[GitHub] metron issue #827: METRON-1294: IP addresses are not formatted correctly in ...

Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/827 @JonZeolla I think we should just remove it for now and I've done that in the latest commit. I'm not entirely clear on what we should expect in this case and we don't need it right now anyways.