[jira] [Updated] (METRON-1633) Incorrect instructions when merging PR into feature branch
[
https://issues.apache.org/jira/browse/METRON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Allen updated METRON-1633:
---
Fix Version/s: Next + 1
> Incorrect instructions when merging PR into feature branch
> --
>
> Key: METRON-1633
> URL: https://issues.apache.org/jira/browse/METRON-1633
> Project: Metron
> Issue Type: Bug
>Reporter: Nick Allen
>Assignee: Nick Allen
>Priority: Minor
> Fix For: Next + 1
>
>
> The 'dev-utilities/committer-utils/prepare-commit' script can be used to
> merge PRs against a feature branch. The script automatically determines
> which branch the PR should be merged into based on how the contributor
> submitted the PR.
> Instructions are offered at the end of the script, after the local merge has
> completed. These instructions are incorrect when merging into a feature
> branch.
> When merging into a feature branch, the instructions say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream master
> {code}
> But they should say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream feature/METRON-1416-upgrade-solr
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (METRON-1633) Incorrect instructions when merging PR into feature branch
[
https://issues.apache.org/jira/browse/METRON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519771#comment-16519771
]
ASF GitHub Bot commented on METRON-1633:
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/1074
> Incorrect instructions when merging PR into feature branch
> --
>
> Key: METRON-1633
> URL: https://issues.apache.org/jira/browse/METRON-1633
> Project: Metron
> Issue Type: Bug
>Reporter: Nick Allen
>Assignee: Nick Allen
>Priority: Minor
>
> The 'dev-utilities/committer-utils/prepare-commit' script can be used to
> merge PRs against a feature branch. The script automatically determines
> which branch the PR should be merged into based on how the contributor
> submitted the PR.
> Instructions are offered at the end of the script, after the local merge has
> completed. These instructions are incorrect when merging into a feature
> branch.
> When merging into a feature branch, the instructions say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream master
> {code}
> But they should say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream feature/METRON-1416-upgrade-solr
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] metron pull request #1074: METRON-1633 Incorrect instructions when merging P...
Github user asfgit closed the pull request at: https://github.com/apache/metron/pull/1074 ---
[jira] [Commented] (METRON-1625) Merge master into Solr feature branch
[ https://issues.apache.org/jira/browse/METRON-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519762#comment-16519762 ] ASF GitHub Bot commented on METRON-1625: GitHub user nickwallen opened a pull request: https://github.com/apache/metron/pull/1075 METRON-1625 Merge master into Solr feature branch Merges the latest from master into the Solr feature branch. ## Pull Request Checklist - [ ] Is there a JIRA ticket associated with this PR? If not one needs to be created at [Metron Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel). - [ ] Does your PR title start with METRON- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Have you included steps to reproduce the behavior or problem that is being changed or addressed? - [ ] Have you included steps or a guide to how the change may be verified and tested manually? - [ ] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via: - [ ] Have you written or updated unit tests and or integration tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent? You can merge this pull request into a Git repository by running: $ git pull https://github.com/nickwallen/metron SOLR-MERGE-MASTER-20180621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/metron/pull/1075.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1075 commit 0bb358009f1823fd19682ddb18d00aefa1441bf6 Author: nickwallen Date: 2018-06-18T15:29:53Z METRON-1573 Enhance KAFKA_* functions to return partition and offset details (nickwallen) closes apache/metron#1030 commit 36b20297b7f385202387b22087a5e85d92e55bc7 Author: merrimanr Date: 2018-06-18T21:35:51Z METRON-1616 Changing alert status fails if no metaalerts have been created yet (merrimanr) closes apache/metron#1061 commit 742734885a215a4a9a363b8e5a88c37fd8e3010d Author: nickwallen Date: 2018-06-19T16:28:43Z METRON-1599 Allow user to define global property 'source.type.field' in Ambari (nickwallen) closes apache/metron#1047 commit 53d074f895e658efca10f046866c33e153010640 Author: nickwallen Date: 2018-06-19T17:35:49Z METRON-1622 Allow user to define global property 'threat.triage.score.field' in Ambari (nickwallen) closes apache/metron#1066 commit 29d6e900c23b9808cb486a153313125cf8d290e4 Author: justinleet Date: 2018-06-19T18:18:02Z METRON-1611 Increment master version number to 0.5.1 for on-going development (justinleet) closes apache/metron#1057 commit e30f77a023983235a0cb835d977f146ee02d8045 Author: sardell Date: 2018-06-20T14:52:52Z METRON-1626 Alerts UI: An empty result is returned when searching for a single alert contained in a metaalert (sardell via nickwallen) closes apache/metron#1068 commit e7efd48d1402b1619c4ab5fc36ce4a7c5b0a058d Author: sardell Date: 2018-06-20T15:36:47Z METRON-1627 Alerts UI: Metaalert details missing in details panel when trying to add alert to existing metaalert (sardell via justinleet) closes apache/metron#1070 commit 6a325cb5b5971fb7e2e3ab8d4407cccab0c784ec Author: merrimanr Date: 2018-06-21T15:39:30Z METRON-1630 Add threat.triage.score.field to READMEs (merrimanr) closes apache/metron#1073 commit 78d5dbd82b8580586f547743c6c55c3f55591f0d Author: Nick Allen Date: 2018-06-21T20:26:28Z Merge remote-tracking branch 'apache/master' into SOLR-MERGE-MASTER-20180621 > Merge master into Solr feature branch > - > > Key: METRON-1625 > URL: https://issues.apache.org/jira/browse/METRON-1625 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > A PR was recently merged to master > ([https://github.com/apache/metron/pull/1061)] with changes to ES DAO > classes. Due to the significant refactor of the DAO layer in this feature > branch it was not a clean merge and a review is appropriate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron pull request #1075: METRON-1625 Merge master into Solr feature branch
GitHub user nickwallen opened a pull request: https://github.com/apache/metron/pull/1075 METRON-1625 Merge master into Solr feature branch Merges the latest from master into the Solr feature branch. ## Pull Request Checklist - [ ] Is there a JIRA ticket associated with this PR? If not one needs to be created at [Metron Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel). - [ ] Does your PR title start with METRON- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Have you included steps to reproduce the behavior or problem that is being changed or addressed? - [ ] Have you included steps or a guide to how the change may be verified and tested manually? - [ ] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via: - [ ] Have you written or updated unit tests and or integration tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent? You can merge this pull request into a Git repository by running: $ git pull https://github.com/nickwallen/metron SOLR-MERGE-MASTER-20180621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/metron/pull/1075.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1075 commit 0bb358009f1823fd19682ddb18d00aefa1441bf6 Author: nickwallen Date: 2018-06-18T15:29:53Z METRON-1573 Enhance KAFKA_* functions to return partition and offset details (nickwallen) closes apache/metron#1030 commit 36b20297b7f385202387b22087a5e85d92e55bc7 Author: merrimanr Date: 2018-06-18T21:35:51Z METRON-1616 Changing alert status fails if no metaalerts have been created yet (merrimanr) closes apache/metron#1061 commit 742734885a215a4a9a363b8e5a88c37fd8e3010d Author: nickwallen Date: 2018-06-19T16:28:43Z METRON-1599 Allow user to define global property 'source.type.field' in Ambari (nickwallen) closes apache/metron#1047 commit 53d074f895e658efca10f046866c33e153010640 Author: nickwallen Date: 2018-06-19T17:35:49Z METRON-1622 Allow user to define global property 'threat.triage.score.field' in Ambari (nickwallen) closes apache/metron#1066 commit 29d6e900c23b9808cb486a153313125cf8d290e4 Author: justinleet Date: 2018-06-19T18:18:02Z METRON-1611 Increment master version number to 0.5.1 for on-going development (justinleet) closes apache/metron#1057 commit e30f77a023983235a0cb835d977f146ee02d8045 Author: sardell Date: 2018-06-20T14:52:52Z METRON-1626 Alerts UI: An empty result is returned when searching for a single alert contained in a metaalert (sardell via nickwallen) closes apache/metron#1068 commit e7efd48d1402b1619c4ab5fc36ce4a7c5b0a058d Author: sardell Date: 2018-06-20T15:36:47Z METRON-1627 Alerts UI: Metaalert details missing in details panel when trying to add alert to existing metaalert (sardell via justinleet) closes apache/metron#1070 commit 6a325cb5b5971fb7e2e3ab8d4407cccab0c784ec Author: merrimanr Date: 2018-06-21T15:39:30Z METRON-1630 Add threat.triage.score.field to READMEs (merrimanr) closes apache/metron#1073 commit 78d5dbd82b8580586f547743c6c55c3f55591f0d Author: Nick Allen Date: 2018-06-21T20:26:28Z Merge remote-tracking branch 'apache/master' into SOLR-MERGE-MASTER-20180621 ---
[jira] [Commented] (METRON-1618) Stellar boolean expressions should treat missing variables as false
[ https://issues.apache.org/jira/browse/METRON-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519728#comment-16519728 ] ASF GitHub Bot commented on METRON-1618: Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1063 I tested this in full dev and it worked fine. I feel like this is a nice improvement and makes it easier to use. I would give it my +1 when the doc and testing requests made by others are done. > Stellar boolean expressions should treat missing variables as false > --- > > Key: METRON-1618 > URL: https://issues.apache.org/jira/browse/METRON-1618 > Project: Metron > Issue Type: Improvement >Reporter: Casey Stella >Priority: Major > > Currently, we treat missing variables as null in boolean expressions rather > than false. If we did adopted a more javascripty approach, stellar would be > easier to use and require fewer existence checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1063: METRON-1618: Stellar boolean expressions should treat mi...
Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1063 I tested this in full dev and it worked fine. I feel like this is a nice improvement and makes it easier to use. I would give it my +1 when the doc and testing requests made by others are done. ---
[jira] [Commented] (METRON-1629) Update Solr documentation
[ https://issues.apache.org/jira/browse/METRON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519664#comment-16519664 ] ASF GitHub Bot commented on METRON-1629: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1072 This looks good. Thanks for taking another swing through these! +1 > Update Solr documentation > - > > Key: METRON-1629 > URL: https://issues.apache.org/jira/browse/METRON-1629 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > The documentation in various READMEs is likely out of date and needs to be > reviewed and updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1072: METRON-1629: Update Solr documentation
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1072 This looks good. Thanks for taking another swing through these! +1 ---
[jira] [Commented] (METRON-1629) Update Solr documentation
[ https://issues.apache.org/jira/browse/METRON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519628#comment-16519628 ] ASF GitHub Bot commented on METRON-1629: Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1072 Thanks for finding those @justinleet. I added more documentation to those sections. Let me know what you think. > Update Solr documentation > - > > Key: METRON-1629 > URL: https://issues.apache.org/jira/browse/METRON-1629 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > The documentation in various READMEs is likely out of date and needs to be > reviewed and updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1072: METRON-1629: Update Solr documentation
Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1072 Thanks for finding those @justinleet. I added more documentation to those sections. Let me know what you think. ---
[jira] [Commented] (METRON-1633) Incorrect instructions when merging PR into feature branch
[
https://issues.apache.org/jira/browse/METRON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519602#comment-16519602
]
ASF GitHub Bot commented on METRON-1633:
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1074
+1 by inspection, good catch
> Incorrect instructions when merging PR into feature branch
> --
>
> Key: METRON-1633
> URL: https://issues.apache.org/jira/browse/METRON-1633
> Project: Metron
> Issue Type: Bug
>Reporter: Nick Allen
>Assignee: Nick Allen
>Priority: Minor
>
> The 'dev-utilities/committer-utils/prepare-commit' script can be used to
> merge PRs against a feature branch. The script automatically determines
> which branch the PR should be merged into based on how the contributor
> submitted the PR.
> Instructions are offered at the end of the script, after the local merge has
> completed. These instructions are incorrect when merging into a feature
> branch.
> When merging into a feature branch, the instructions say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream master
> {code}
> But they should say...
> {code}
> Review commit carefully then run...
> cd /Users/nallen/tmp/metron-pr1056
> git push upstream feature/METRON-1416-upgrade-solr
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] metron issue #1074: METRON-1633 Incorrect instructions when merging PR into ...
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1074 +1 by inspection, good catch ---
[jira] [Commented] (METRON-1633) Incorrect instructions when merging PR into feature branch
[ https://issues.apache.org/jira/browse/METRON-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519533#comment-16519533 ] ASF GitHub Bot commented on METRON-1633: GitHub user nickwallen opened a pull request: https://github.com/apache/metron/pull/1074 METRON-1633 Incorrect instructions when merging PR into feature branch ## Description The 'dev-utilities/committer-utils/prepare-commit' script can be used to merge PRs against a feature branch. The script automatically determines which branch the PR should be merged into based on how the contributor submitted the PR. Instructions are offered at the end of the script, after the local merge has completed. These instructions are incorrect when merging into a feature branch. When merging into a feature branch, the instructions say... ``` Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream master ``` But they should say... ``` Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream feature/METRON-1416-upgrade-solr ``` ## Testing Test merge a PR against a feature branch using a PR like #1056... ``` $ ./dev-utilities/committer-utils/prepare-commit ...using settings from /Users/nallen/.metron-prepare-commit [1] metron [2] metron-bro-plugin-kafka which repo? [1]: pull request: 1056 local working directory [/Users/nallen/tmp/metron-pr1056]: origin repo [https://github.com/apache/metron]: base branch to merge into [feature/METRON-1416-upgrade-solr]: Cloning into '/Users/nallen/tmp/metron-pr1056'... remote: Counting objects: 42368, done. remote: Compressing objects: 100% (56/56), done. remote: Total 42368 (delta 15), reused 19 (delta 5), pack-reused 42304 Receiving objects: 100% (42368/42368), 59.85 MiB | 10.35 MiB/s, done. Resolving deltas: 100% (16385/16385), done. From https://git-wip-us.apache.org/repos/asf/metron * branch feature/METRON-1416-upgrade-solr -> FETCH_HEAD * [new branch]feature/METRON-1416-upgrade-solr -> upstream/feature/METRON-1416-upgrade-solr Branch 'feature/METRON-1416-upgrade-solr' set up to track remote branch 'feature/METRON-1416-upgrade-solr' from 'upstream'. Switched to a new branch 'feature/METRON-1416-upgrade-solr' remote: Counting objects: 66, done. remote: Compressing objects: 100% (22/22), done. remote: Total 66 (delta 26), reused 52 (delta 24), pack-reused 11 Unpacking objects: 100% (66/66), done. From https://github.com/apache/metron * [new ref] refs/pull/1056/head -> pr-1056 github contributor's username [nickwallen]: github contributor's email [n...@nickallen.org]: issue identifier in jira [METRON-1609]: issue description [Elasticsearch settings in Ambari should not be required if Solr is the indexer]: commit message [METRON-1609 Elasticsearch settings in Ambari should not be required if Solr is the indexer (nickwallen) closes apache/metron#1056]: Squash commit -- not updating HEAD Automatic merge went well; stopped before committing as requested On branch feature/METRON-1416-upgrade-solr Your branch is up to date with 'upstream/feature/METRON-1416-upgrade-solr'. nothing to commit, working tree clean run test suite? [yN] Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream feature/METRON-1416-upgrade-solr ``` Test a merge against master using a PR like #1069. ``` $ ./dev-utilities/committer-utils/prepare-commit ...using settings from /Users/nallen/.metron-prepare-commit [1] metron [2] metron-bro-plugin-kafka which repo? [1]: pull request: 1069 local working directory [/Users/nallen/tmp/metron-pr1069]: origin repo [https://github.com/apache/metron]: base branch to merge into [master]: Cloning into '/Users/nallen/tmp/metron-pr1069'... remote: Counting objects: 42368, done. remote: Compressing objects: 100% (56/56), done. remote: Total 42368 (delta 15), reused 19 (delta 5), pack-reused 42304 Receiving objects: 100% (42368/42368), 59.85 MiB | 10.13 MiB/s, done. Resolving deltas: 100% (16385/16385), done. Checking out files: 100% (2677/2677), done. From https://git-wip-us.apache.org/repos/asf/metron * branch master -> FETCH_HEAD * [new branch]master -> upstream/master Already on 'master' Your branch is up to date with 'origin/master'. Already up to date. remote: Counting objects: 22, done. remote: Total 22 (delta 11), reused 11 (delta 11), pack-reused 11 Unpacking objects: 100% (22/22), done. From
[GitHub] metron pull request #1074: METRON-1633 Incorrect instructions when merging P...
GitHub user nickwallen opened a pull request: https://github.com/apache/metron/pull/1074 METRON-1633 Incorrect instructions when merging PR into feature branch ## Description The 'dev-utilities/committer-utils/prepare-commit' script can be used to merge PRs against a feature branch. The script automatically determines which branch the PR should be merged into based on how the contributor submitted the PR. Instructions are offered at the end of the script, after the local merge has completed. These instructions are incorrect when merging into a feature branch. When merging into a feature branch, the instructions say... ``` Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream master ``` But they should say... ``` Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream feature/METRON-1416-upgrade-solr ``` ## Testing Test merge a PR against a feature branch using a PR like #1056... ``` $ ./dev-utilities/committer-utils/prepare-commit ...using settings from /Users/nallen/.metron-prepare-commit [1] metron [2] metron-bro-plugin-kafka which repo? [1]: pull request: 1056 local working directory [/Users/nallen/tmp/metron-pr1056]: origin repo [https://github.com/apache/metron]: base branch to merge into [feature/METRON-1416-upgrade-solr]: Cloning into '/Users/nallen/tmp/metron-pr1056'... remote: Counting objects: 42368, done. remote: Compressing objects: 100% (56/56), done. remote: Total 42368 (delta 15), reused 19 (delta 5), pack-reused 42304 Receiving objects: 100% (42368/42368), 59.85 MiB | 10.35 MiB/s, done. Resolving deltas: 100% (16385/16385), done. From https://git-wip-us.apache.org/repos/asf/metron * branch feature/METRON-1416-upgrade-solr -> FETCH_HEAD * [new branch]feature/METRON-1416-upgrade-solr -> upstream/feature/METRON-1416-upgrade-solr Branch 'feature/METRON-1416-upgrade-solr' set up to track remote branch 'feature/METRON-1416-upgrade-solr' from 'upstream'. Switched to a new branch 'feature/METRON-1416-upgrade-solr' remote: Counting objects: 66, done. remote: Compressing objects: 100% (22/22), done. remote: Total 66 (delta 26), reused 52 (delta 24), pack-reused 11 Unpacking objects: 100% (66/66), done. From https://github.com/apache/metron * [new ref] refs/pull/1056/head -> pr-1056 github contributor's username [nickwallen]: github contributor's email [n...@nickallen.org]: issue identifier in jira [METRON-1609]: issue description [Elasticsearch settings in Ambari should not be required if Solr is the indexer]: commit message [METRON-1609 Elasticsearch settings in Ambari should not be required if Solr is the indexer (nickwallen) closes apache/metron#1056]: Squash commit -- not updating HEAD Automatic merge went well; stopped before committing as requested On branch feature/METRON-1416-upgrade-solr Your branch is up to date with 'upstream/feature/METRON-1416-upgrade-solr'. nothing to commit, working tree clean run test suite? [yN] Review commit carefully then run... cd /Users/nallen/tmp/metron-pr1056 git push upstream feature/METRON-1416-upgrade-solr ``` Test a merge against master using a PR like #1069. ``` $ ./dev-utilities/committer-utils/prepare-commit ...using settings from /Users/nallen/.metron-prepare-commit [1] metron [2] metron-bro-plugin-kafka which repo? [1]: pull request: 1069 local working directory [/Users/nallen/tmp/metron-pr1069]: origin repo [https://github.com/apache/metron]: base branch to merge into [master]: Cloning into '/Users/nallen/tmp/metron-pr1069'... remote: Counting objects: 42368, done. remote: Compressing objects: 100% (56/56), done. remote: Total 42368 (delta 15), reused 19 (delta 5), pack-reused 42304 Receiving objects: 100% (42368/42368), 59.85 MiB | 10.13 MiB/s, done. Resolving deltas: 100% (16385/16385), done. Checking out files: 100% (2677/2677), done. From https://git-wip-us.apache.org/repos/asf/metron * branch master -> FETCH_HEAD * [new branch]master -> upstream/master Already on 'master' Your branch is up to date with 'origin/master'. Already up to date. remote: Counting objects: 22, done. remote: Total 22 (delta 11), reused 11 (delta 11), pack-reused 11 Unpacking objects: 100% (22/22), done. From https://github.com/apache/metron * [new ref] refs/pull/1069/head -> pr-1069 github contributor's username [nickwallen]: github contributor's email [n...@nickallen.org]: issue identifier in jira [METRON-1624]:
[jira] [Created] (METRON-1633) Incorrect instructions when merging PR into feature branch
Nick Allen created METRON-1633:
--
Summary: Incorrect instructions when merging PR into feature branch
Key: METRON-1633
URL: https://issues.apache.org/jira/browse/METRON-1633
Project: Metron
Issue Type: Bug
Reporter: Nick Allen
Assignee: Nick Allen
The 'dev-utilities/committer-utils/prepare-commit' script can be used to merge
PRs against a feature branch. The script automatically determines which branch
the PR should be merged into based on how the contributor submitted the PR.
Instructions are offered at the end of the script, after the local merge has
completed. These instructions are incorrect when merging into a feature branch.
When merging into a feature branch, the instructions say...
{code}
Review commit carefully then run...
cd /Users/nallen/tmp/metron-pr1056
git push upstream master
{code}
But they should say...
{code}
Review commit carefully then run...
cd /Users/nallen/tmp/metron-pr1056
git push upstream feature/METRON-1416-upgrade-solr
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (METRON-1425) Test and run Solr deployment in multinode environment
[ https://issues.apache.org/jira/browse/METRON-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Leet reassigned METRON-1425: --- Assignee: James Sirota > Test and run Solr deployment in multinode environment > - > > Key: METRON-1425 > URL: https://issues.apache.org/jira/browse/METRON-1425 > Project: Metron > Issue Type: Sub-task >Reporter: Justin Leet >Assignee: James Sirota >Priority: Major > > We need multinode testing, similar to how the ES5 upgrade did, on multinode > deployments. For the ES5 upgrade, this revealed issues that needed to be > resolved, and this is likely to be the same for Solr. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron pull request #1073: METRON-1630: Add threat.triage.score.field to REA...
Github user asfgit closed the pull request at: https://github.com/apache/metron/pull/1073 ---
[jira] [Commented] (METRON-1630) Add threat.triage.score.field to READMEs
[ https://issues.apache.org/jira/browse/METRON-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519522#comment-16519522 ] ASF GitHub Bot commented on METRON-1630: Github user asfgit closed the pull request at: https://github.com/apache/metron/pull/1073 > Add threat.triage.score.field to READMEs > > > Key: METRON-1630 > URL: https://issues.apache.org/jira/browse/METRON-1630 > Project: Metron > Issue Type: Bug >Reporter: Ryan Merriman >Priority: Major > > This global config setting should be documented in the READMEs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (METRON-1609) Elasticsearch settings in Ambari should not be required if Solr is the indexer
[ https://issues.apache.org/jira/browse/METRON-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519510#comment-16519510 ] ASF GitHub Bot commented on METRON-1609: Github user nickwallen closed the pull request at: https://github.com/apache/metron/pull/1056 > Elasticsearch settings in Ambari should not be required if Solr is the indexer > -- > > Key: METRON-1609 > URL: https://issues.apache.org/jira/browse/METRON-1609 > Project: Metron > Issue Type: Sub-task >Reporter: Nick Allen >Assignee: Nick Allen >Priority: Major > Attachments: Screen Shot 2018-06-06 at 12.34.13 PM.png, Screen Shot > 2018-06-06 at 12.37.08 PM.png > > > When a user deploys Metron with Solr, the Mpack requires that the user > populate the Index Settings > Elasticsearch Hosts field to continue, even > when deploying a Metron cluster that indexes to Solr. > The other Elasticsearch specific fields on the Index Settings page are also > required, although defaults are provided and thus the user is not required to > enter anything here. If you remove the provided defaults, you can see that > each of the fields are required, even when Elasticsearch will not be used. > * The Elasticsearch related properties under the Ambari 'Index settings' tab > should only be required if Elasticsearch is chosen as the indexer. > * The Solr related properties under the 'Index Settings' tab should only be > required if Solr is chosen as the indexer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (METRON-1609) Elasticsearch settings in Ambari should not be required if Solr is the indexer
[ https://issues.apache.org/jira/browse/METRON-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519509#comment-16519509 ] ASF GitHub Bot commented on METRON-1609: Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/1056 This has been merged > Elasticsearch settings in Ambari should not be required if Solr is the indexer > -- > > Key: METRON-1609 > URL: https://issues.apache.org/jira/browse/METRON-1609 > Project: Metron > Issue Type: Sub-task >Reporter: Nick Allen >Assignee: Nick Allen >Priority: Major > Attachments: Screen Shot 2018-06-06 at 12.34.13 PM.png, Screen Shot > 2018-06-06 at 12.37.08 PM.png > > > When a user deploys Metron with Solr, the Mpack requires that the user > populate the Index Settings > Elasticsearch Hosts field to continue, even > when deploying a Metron cluster that indexes to Solr. > The other Elasticsearch specific fields on the Index Settings page are also > required, although defaults are provided and thus the user is not required to > enter anything here. If you remove the provided defaults, you can see that > each of the fields are required, even when Elasticsearch will not be used. > * The Elasticsearch related properties under the Ambari 'Index settings' tab > should only be required if Elasticsearch is chosen as the indexer. > * The Solr related properties under the 'Index Settings' tab should only be > required if Solr is chosen as the indexer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1056: METRON-1609 Elasticsearch settings in Ambari should not ...
Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/1056 This has been merged ---
[GitHub] metron pull request #1056: METRON-1609 Elasticsearch settings in Ambari shou...
Github user nickwallen closed the pull request at: https://github.com/apache/metron/pull/1056 ---
[jira] [Commented] (METRON-1609) Elasticsearch settings in Ambari should not be required if Solr is the indexer
[ https://issues.apache.org/jira/browse/METRON-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519495#comment-16519495 ] ASF GitHub Bot commented on METRON-1609: Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/1056 Thanks for the review and all the testing guys! Will merge now. > Elasticsearch settings in Ambari should not be required if Solr is the indexer > -- > > Key: METRON-1609 > URL: https://issues.apache.org/jira/browse/METRON-1609 > Project: Metron > Issue Type: Sub-task >Reporter: Nick Allen >Assignee: Nick Allen >Priority: Major > Attachments: Screen Shot 2018-06-06 at 12.34.13 PM.png, Screen Shot > 2018-06-06 at 12.37.08 PM.png > > > When a user deploys Metron with Solr, the Mpack requires that the user > populate the Index Settings > Elasticsearch Hosts field to continue, even > when deploying a Metron cluster that indexes to Solr. > The other Elasticsearch specific fields on the Index Settings page are also > required, although defaults are provided and thus the user is not required to > enter anything here. If you remove the provided defaults, you can see that > each of the fields are required, even when Elasticsearch will not be used. > * The Elasticsearch related properties under the Ambari 'Index settings' tab > should only be required if Elasticsearch is chosen as the indexer. > * The Solr related properties under the 'Index Settings' tab should only be > required if Solr is chosen as the indexer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1056: METRON-1609 Elasticsearch settings in Ambari should not ...
Github user nickwallen commented on the issue: https://github.com/apache/metron/pull/1056 Thanks for the review and all the testing guys! Will merge now. ---
[jira] [Commented] (METRON-1609) Elasticsearch settings in Ambari should not be required if Solr is the indexer
[ https://issues.apache.org/jira/browse/METRON-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519488#comment-16519488 ] ASF GitHub Bot commented on METRON-1609: Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1056 I tested this in full dev and went through the testing instructions. REST now throws an error on restart. Thanks! +1 > Elasticsearch settings in Ambari should not be required if Solr is the indexer > -- > > Key: METRON-1609 > URL: https://issues.apache.org/jira/browse/METRON-1609 > Project: Metron > Issue Type: Sub-task >Reporter: Nick Allen >Assignee: Nick Allen >Priority: Major > Attachments: Screen Shot 2018-06-06 at 12.34.13 PM.png, Screen Shot > 2018-06-06 at 12.37.08 PM.png > > > When a user deploys Metron with Solr, the Mpack requires that the user > populate the Index Settings > Elasticsearch Hosts field to continue, even > when deploying a Metron cluster that indexes to Solr. > The other Elasticsearch specific fields on the Index Settings page are also > required, although defaults are provided and thus the user is not required to > enter anything here. If you remove the provided defaults, you can see that > each of the fields are required, even when Elasticsearch will not be used. > * The Elasticsearch related properties under the Ambari 'Index settings' tab > should only be required if Elasticsearch is chosen as the indexer. > * The Solr related properties under the 'Index Settings' tab should only be > required if Solr is chosen as the indexer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1056: METRON-1609 Elasticsearch settings in Ambari should not ...
Github user merrimanr commented on the issue: https://github.com/apache/metron/pull/1056 I tested this in full dev and went through the testing instructions. REST now throws an error on restart. Thanks! +1 ---
[jira] [Commented] (METRON-1630) Add threat.triage.score.field to READMEs
[ https://issues.apache.org/jira/browse/METRON-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519485#comment-16519485 ] ASF GitHub Bot commented on METRON-1630: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1073 +1 by inspection > Add threat.triage.score.field to READMEs > > > Key: METRON-1630 > URL: https://issues.apache.org/jira/browse/METRON-1630 > Project: Metron > Issue Type: Bug >Reporter: Ryan Merriman >Priority: Major > > This global config setting should be documented in the READMEs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1073: METRON-1630: Add threat.triage.score.field to READMEs
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1073 +1 by inspection ---
[jira] [Commented] (METRON-1555) Update REST to run YARN and MR jobs
[ https://issues.apache.org/jira/browse/METRON-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519457#comment-16519457 ] ASF GitHub Bot commented on METRON-1555: Github user merrimanr closed the pull request at: https://github.com/apache/metron/pull/1019 > Update REST to run YARN and MR jobs > --- > > Key: METRON-1555 > URL: https://issues.apache.org/jira/browse/METRON-1555 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > This task involves enabling REST to submit YARN or MR jobs. We will likely > need to: > * update Maven dependencies to include YARN and MR libraries in the > classpath and resolve any version conflicts > * update REST start script to include properties required for YARN > * update the MPack for any additional setup work (create user HDFS directory > for example) and properties needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (METRON-1555) Update REST to run YARN and MR jobs
[
https://issues.apache.org/jira/browse/METRON-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519458#comment-16519458
]
ASF GitHub Bot commented on METRON-1555:
GitHub user merrimanr reopened a pull request:
https://github.com/apache/metron/pull/1019
METRON-1555: Update REST to run YARN and MR jobs
## Contributor Comments
This PR sets us up to run YARN and MR jobs inside our REST application.
Changes include:
- addition of maven dependencies
- addition of -Dhdp.version parameter to the REST startup script
- MPack now supplies the hdp.version parameter
- MPack now sets up a "metron" service user HDFS directory needed for
running MR jobs
- MPack now sets up a pcap HDFS directory
- addition of a Pcap controller with a single Fixed Pcap Query endpoint and
service to demonstrate running MR jobs in REST
The fixed pcap query endpoint submitted here should match the functionality
in the metron-api module with a few minor differences:
- the default input and output paths are spring properties instead of
hardcoded in classes (this will make it easier to expose them in Ambari if we
choose to)
- query results are not cleaned up automatically since that work is
captured in a separate Jira
- num reducers is defaulted to 1 instead of 10
Unit and integration tests are included and this has been tested in full
dev. I tested this by generating sample pcap data with the
PcapTopologyIntegrationTest. You can do this by either:
- running the test in your IDE and pausing it after the topology has
generated data
- commenting out `clearOutDir(outDir);` and running the test
Pcap data should be present in
`/metron/metron-platform/metron-pcap-backend/target/pcap/data_dir`. Upload the
`pcap*` files to the `/apps/metron/pcap` directory in HDFS. You should be able
to perform the tests in PcapTopologyIntegrationTest using REST and get the same
results.
For example:
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"endTime": 1458240269424,
"startTime": 1458240269419
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 2 pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 20 pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"ipDstAddr":"207.28.210.1"
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return no pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"ipDstPort": 22
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 10 pcap results.
Related discussion can be found here:
http://mail-archives.apache.org/mod_mbox/metron-dev/201805.mbox/%3ccaevkqpbxzjnu_wgrbfwnz-mvqnkb7mthedveq9plyhwfit7...@mail.gmail.com%3E
## Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our [Development
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
for the complete guide to follow for contributions.
Please refer also to our [Build Verification
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow
these guidelines and ask you to double check the following:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to
be created at [Metron
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
- [x] Does your PR title start with METRON- where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically master)?
### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is
being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified
and tested manually?
- [] Have you ensured that the full suite of tests and checks have been
executed in the root metron folder via:
```
mvn -q clean integration-test install &&
dev-utilities/build-utils/verify_licenses.sh
```
- [ ] Have you written or updated unit tests and or integration tests to
verify your changes?
- [x] If adding new dependencies to the code, are these dependencies
licensed
[GitHub] metron pull request #1019: METRON-1555: Update REST to run YARN and MR jobs
GitHub user merrimanr reopened a pull request:
https://github.com/apache/metron/pull/1019
METRON-1555: Update REST to run YARN and MR jobs
## Contributor Comments
This PR sets us up to run YARN and MR jobs inside our REST application.
Changes include:
- addition of maven dependencies
- addition of -Dhdp.version parameter to the REST startup script
- MPack now supplies the hdp.version parameter
- MPack now sets up a "metron" service user HDFS directory needed for
running MR jobs
- MPack now sets up a pcap HDFS directory
- addition of a Pcap controller with a single Fixed Pcap Query endpoint and
service to demonstrate running MR jobs in REST
The fixed pcap query endpoint submitted here should match the functionality
in the metron-api module with a few minor differences:
- the default input and output paths are spring properties instead of
hardcoded in classes (this will make it easier to expose them in Ambari if we
choose to)
- query results are not cleaned up automatically since that work is
captured in a separate Jira
- num reducers is defaulted to 1 instead of 10
Unit and integration tests are included and this has been tested in full
dev. I tested this by generating sample pcap data with the
PcapTopologyIntegrationTest. You can do this by either:
- running the test in your IDE and pausing it after the topology has
generated data
- commenting out `clearOutDir(outDir);` and running the test
Pcap data should be present in
`/metron/metron-platform/metron-pcap-backend/target/pcap/data_dir`. Upload the
`pcap*` files to the `/apps/metron/pcap` directory in HDFS. You should be able
to perform the tests in PcapTopologyIntegrationTest using REST and get the same
results.
For example:
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"endTime": 1458240269424,
"startTime": 1458240269419
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 2 pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 20 pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"ipDstAddr":"207.28.210.1"
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return no pcap results.
```
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '{
"ipDstPort": 22
}' 'http://node1:8082/api/v1/pcap/fixed'
```
should return 10 pcap results.
Related discussion can be found here:
http://mail-archives.apache.org/mod_mbox/metron-dev/201805.mbox/%3ccaevkqpbxzjnu_wgrbfwnz-mvqnkb7mthedveq9plyhwfit7...@mail.gmail.com%3E
## Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our [Development
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
for the complete guide to follow for contributions.
Please refer also to our [Build Verification
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow
these guidelines and ask you to double check the following:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to
be created at [Metron
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
- [x] Does your PR title start with METRON- where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically master)?
### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is
being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified
and tested manually?
- [] Have you ensured that the full suite of tests and checks have been
executed in the root metron folder via:
```
mvn -q clean integration-test install &&
dev-utilities/build-utils/verify_licenses.sh
```
- [ ] Have you written or updated unit tests and or integration tests to
verify your changes?
- [x] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] Have you verified the basic functionality of the build by building
and running locally with Vagrant full-dev
[GitHub] metron pull request #1019: METRON-1555: Update REST to run YARN and MR jobs
Github user merrimanr closed the pull request at: https://github.com/apache/metron/pull/1019 ---
[jira] [Created] (METRON-1632) Cannot filter by metaalert parents fields in Solr
Justin Leet created METRON-1632:
---
Summary: Cannot filter by metaalert parents fields in Solr
Key: METRON-1632
URL: https://issues.apache.org/jira/browse/METRON-1632
Project: Metron
Issue Type: Sub-task
Reporter: Justin Leet
>From the alerts UI, attempt to filter by source.type:metaalert. No results
>will be returned. Similar results happen on other parent fields in metaalerts
>(but these are primarily metadata fields that wouldn't usually be filtered on,
>e.g. the 'groups' field that maintains the UI groupings that led to the
>creation of that metaalert in the first place).
After creating metaalert(s), this query, for example returns no results:
{code}
curl -X POST --header 'Content-Type: application/json' --header 'Accept:
application/json' -d '
{ "from": 0, "indices": [ "metaalert" ], "query": "source.type:metaalert",
"size": 5 }
' 'http://node1:8082/api/v1/search/search'
{code}
There should be results returned if metalaerts exist.
h5. Root Cause Analysis
This is because in Solr, we used nested objects to handle metaalerts.
For example, for the following query:
{code}
“ip.src.addr:192.168.1.1 AND source.type:metaalert”, we turn it into
{!parent which=source.type:metaalert v='ip_src_addr:192.168.1.1 AND
source.type:metaalert'}{code}
The “v=” syntax is just the syntax used to handle complicated clauses in the
element described in the link.
The catch here is that this filters on children alone, i.e. this query also
won’t get applied to the parent. For many queries this isn’t a big deal because
metaalerts don’t contain most fields, e.g. querying on ip.src.addr alone is a
child only field and functions as expected. However, anything at the parent
level, e.g. source.type:metaalert, won’t be matched by the query. This causes
queries acting attempting with a parent field to fail (In particular, being
AND’ed with a parent field).
The fields at the parent level I reasonably expect to be queried are
source.type – It’s the one that gets used a lot and shows up visibly. This is
the most important field to handle, particularly for UI reasons.
threat.triage.field – It’s substantially less likely, but someone could want to
search it.
The correct way to handle this, per the link above, is to do something like
{code:java}
+source.type:metaalert +
{!parent which=source.type:metaalert v='ip_src_addr:192.168.1.1’ }{code}
What this does is pull the parent specific filter out in front of the query and
treats it as an AND while the child specific portion is kept contained in the
“v=” clause.
Unfortunately, this is a bit more involved than what we currently have because
it involves a deeper understanding of the query than just plugging in what the
UI grabs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (METRON-1555) Update REST to run YARN and MR jobs
[ https://issues.apache.org/jira/browse/METRON-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519384#comment-16519384 ] ASF GitHub Bot commented on METRON-1555: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1019 @merrimanr Can you kick Travis? > Update REST to run YARN and MR jobs > --- > > Key: METRON-1555 > URL: https://issues.apache.org/jira/browse/METRON-1555 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > This task involves enabling REST to submit YARN or MR jobs. We will likely > need to: > * update Maven dependencies to include YARN and MR libraries in the > classpath and resolve any version conflicts > * update REST start script to include properties required for YARN > * update the MPack for any additional setup work (create user HDFS directory > for example) and properties needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1019: METRON-1555: Update REST to run YARN and MR jobs
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1019 @merrimanr Can you kick Travis? ---
[jira] [Commented] (METRON-1555) Update REST to run YARN and MR jobs
[ https://issues.apache.org/jira/browse/METRON-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519383#comment-16519383 ] ASF GitHub Bot commented on METRON-1555: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1019 I'm good with this right now with the follow-on changes and tests, assuming @mmiklavc is good. I do have the same concerns Mike had, but I think being watchful going forward is a good compromise, but that involves a bit of vigilance here. > Update REST to run YARN and MR jobs > --- > > Key: METRON-1555 > URL: https://issues.apache.org/jira/browse/METRON-1555 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > This task involves enabling REST to submit YARN or MR jobs. We will likely > need to: > * update Maven dependencies to include YARN and MR libraries in the > classpath and resolve any version conflicts > * update REST start script to include properties required for YARN > * update the MPack for any additional setup work (create user HDFS directory > for example) and properties needed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1019: METRON-1555: Update REST to run YARN and MR jobs
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1019 I'm good with this right now with the follow-on changes and tests, assuming @mmiklavc is good. I do have the same concerns Mike had, but I think being watchful going forward is a good compromise, but that involves a bit of vigilance here. ---
[jira] [Assigned] (METRON-1629) Update Solr documentation
[ https://issues.apache.org/jira/browse/METRON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Leet reassigned METRON-1629: --- Assignee: Ryan Merriman > Update Solr documentation > - > > Key: METRON-1629 > URL: https://issues.apache.org/jira/browse/METRON-1629 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Assignee: Ryan Merriman >Priority: Major > > The documentation in various READMEs is likely out of date and needs to be > reviewed and updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (METRON-1609) Elasticsearch settings in Ambari should not be required if Solr is the indexer
[ https://issues.apache.org/jira/browse/METRON-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519346#comment-16519346 ] ASF GitHub Bot commented on METRON-1609: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1056 I'm +1 by inspection assuming @merrimanr is good. > Elasticsearch settings in Ambari should not be required if Solr is the indexer > -- > > Key: METRON-1609 > URL: https://issues.apache.org/jira/browse/METRON-1609 > Project: Metron > Issue Type: Sub-task >Reporter: Nick Allen >Assignee: Nick Allen >Priority: Major > Attachments: Screen Shot 2018-06-06 at 12.34.13 PM.png, Screen Shot > 2018-06-06 at 12.37.08 PM.png > > > When a user deploys Metron with Solr, the Mpack requires that the user > populate the Index Settings > Elasticsearch Hosts field to continue, even > when deploying a Metron cluster that indexes to Solr. > The other Elasticsearch specific fields on the Index Settings page are also > required, although defaults are provided and thus the user is not required to > enter anything here. If you remove the provided defaults, you can see that > each of the fields are required, even when Elasticsearch will not be used. > * The Elasticsearch related properties under the Ambari 'Index settings' tab > should only be required if Elasticsearch is chosen as the indexer. > * The Solr related properties under the 'Index Settings' tab should only be > required if Solr is chosen as the indexer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (METRON-1631) Alerts UI: Dash score does not show if only filtering by one group
Shane Ardell created METRON-1631: Summary: Alerts UI: Dash score does not show if only filtering by one group Key: METRON-1631 URL: https://issues.apache.org/jira/browse/METRON-1631 Project: Metron Issue Type: Bug Reporter: Shane Ardell Attachments: Screen Shot 2018-06-21 at 2.44.28 PM.png, Screen Shot 2018-06-21 at 2.44.34 PM.png When a user clicks on a single Group By button, the dash score doesn't display. If a user then clicks on another Group By button, the dash score will then display. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (METRON-1629) Update Solr documentation
[ https://issues.apache.org/jira/browse/METRON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519195#comment-16519195 ] ASF GitHub Bot commented on METRON-1629: Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1072 Couple more places to update things: - The first point in https://github.com/apache/metron/blob/master/metron-interface/metron-alerts/README.md#prerequisites should updated to not refer to ES alone - The REST prereqs list here needs the same treatment: https://github.com/apache/metron/blob/master/metron-interface/metron-rest/README.md#prerequisites - The schemas for new sensors need a couple fields defined to work properly, at least `comments` and `metaalerts` (I'm unsure if there's anything more off the top of my head). We'll need something similar to https://github.com/apache/metron/blob/master/metron-platform/metron-indexing/README.md#elasticsearch. This should also be reflected appropriately here: https://github.com/apache/metron/blob/master/metron-platform/metron-parsers/README.md#notes-on-adding-a-new-sensor > Update Solr documentation > - > > Key: METRON-1629 > URL: https://issues.apache.org/jira/browse/METRON-1629 > Project: Metron > Issue Type: Sub-task >Reporter: Ryan Merriman >Priority: Major > > The documentation in various READMEs is likely out of date and needs to be > reviewed and updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] metron issue #1072: METRON-1629: Update Solr documentation
Github user justinleet commented on the issue: https://github.com/apache/metron/pull/1072 Couple more places to update things: - The first point in https://github.com/apache/metron/blob/master/metron-interface/metron-alerts/README.md#prerequisites should updated to not refer to ES alone - The REST prereqs list here needs the same treatment: https://github.com/apache/metron/blob/master/metron-interface/metron-rest/README.md#prerequisites - The schemas for new sensors need a couple fields defined to work properly, at least `comments` and `metaalerts` (I'm unsure if there's anything more off the top of my head). We'll need something similar to https://github.com/apache/metron/blob/master/metron-platform/metron-indexing/README.md#elasticsearch. This should also be reflected appropriately here: https://github.com/apache/metron/blob/master/metron-platform/metron-parsers/README.md#notes-on-adding-a-new-sensor ---
