[jira] [Commented] (METRON-1337) List of facets should not be hardcoded

2018-02-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/METRON-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373669#comment-16373669
 ] 

ASF GitHub Bot commented on METRON-1337:


Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/metron/pull/853#discussion_r170125479
  
--- Diff: 
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/service/impl/AlertServiceImpl.java
 ---
@@ -37,15 +47,21 @@
 @Service
 public class AlertServiceImpl implements AlertService {
 
--- End diff --

I think that is great.  At some point, if we are going to do this a few 
times we should have a standard naming convention ( separators at least or 
something).  But that isn't a thing for this PR


> List of facets should not be hardcoded
> --
>
> Key: METRON-1337
> URL: https://issues.apache.org/jira/browse/METRON-1337
> Project: Metron
>  Issue Type: Bug
>Reporter: Ryan Merriman
>Assignee: Ryan Merriman
>Priority: Major
>
> Currently the facet fields shown in the left panel of the Alerts UI is hard 
> coded in a javascript file.  This should be configurable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (METRON-1337) List of facets should not be hardcoded

2018-02-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/METRON-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373635#comment-16373635
 ] 

ASF GitHub Bot commented on METRON-1337:


Github user merrimanr commented on a diff in the pull request:

https://github.com/apache/metron/pull/853#discussion_r170120909
  
--- Diff: 
metron-interface/metron-rest/src/main/java/org/apache/metron/rest/service/impl/AlertServiceImpl.java
 ---
@@ -37,15 +47,21 @@
 @Service
 public class AlertServiceImpl implements AlertService {
 
--- End diff --

Name is changed in the latest commit.  Let me know what you think.


> List of facets should not be hardcoded
> --
>
> Key: METRON-1337
> URL: https://issues.apache.org/jira/browse/METRON-1337
> Project: Metron
>  Issue Type: Bug
>Reporter: Ryan Merriman
>Assignee: Ryan Merriman
>Priority: Major
>
> Currently the facet fields shown in the left panel of the Alerts UI is hard 
> coded in a javascript file.  This should be configurable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (METRON-1344) Externalize the infrastructural components using integration tests

2018-02-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/METRON-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373584#comment-16373584
 ] 

ASF GitHub Bot commented on METRON-1344:


Github user merrimanr closed the pull request at:

https://github.com/apache/metron/pull/858


> Externalize the infrastructural components using integration tests
> --
>
> Key: METRON-1344
> URL: https://issues.apache.org/jira/browse/METRON-1344
> Project: Metron
>  Issue Type: Improvement
>Reporter: Ryan Merriman
>Assignee: Ryan Merriman
>Priority: Major
>
> As we move towards adding the Alerts UI e2e test to our continuous build, we 
> need to remove the dependence on vagrant full dev and provide equivalent 
> infrastructure within Travis.  This will include all the services that the 
> e2e tests depend on including Kafka, Zookeeper, Elasticsearch (possibly 
> HBase), and Metron REST.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (METRON-1355) Convert metron-elasticsearch to new infrastructure

2018-02-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/METRON-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373557#comment-16373557
 ] 

ASF GitHub Bot commented on METRON-1355:


GitHub user merrimanr opened a pull request:

https://github.com/apache/metron/pull/941

METRON-1355: Convert metron-elasticsearch to new infrastructure

## Contributor Comments
This PR switches metron-elasticsearch integration tests from using 
in-memory components to the e2e Docker infrastructure.  A high-level summary of 
the changes:

- Updated travis to only run the metron-elasticsearch tests
- Updated the Elasticsearch Docker image to the same version as Metron
- Removed the requirement to build a base "metron-centos" image.  Removes 
an extra Docker build step and I'm not sure caching this helps much anyways.
- Updated each integration test to use index names that are namespaced with 
the test class name
- Replaced the in-memory component setup with an Elasticsearch client 
configured for the Elasticsearch Docker container
- Added steps to setup/delete indices before/after each test
- Moved Elasticsearch in-memory helper methods and common integration tests 
methods to a utils class
- Fixed a minor bug in the ElasticsearchMetaAlertDao class where the index 
is always hardcoded to "metaalert"
- Added some initial documentation for the metron-docker-e2e module

The scope of this PR are 3 of the 4 metron-elasticsearch integration tests:

- 
org.apache.metron.elasticsearch.integration.ElasticsearchMetaAlertIntegrationTest
- 
org.apache.metron.elasticsearch.integration.ElasticsearchSearchIntegrationTest
- 
org.apache.metron.elasticsearch.integration.ElasticsearchUpdateIntegrationTest

Most of the test logic in 
org.apache.metron.elasticsearch.integration.ElasticsearchIndexingIntegrationTest
 is actually in metron-indexing so that test will be updated when we convert 
that module.

At this point only the metron-elasticsearch tests are run in travis.  My 
plan is to slowly add tests for each module until we reach feature parity with 
master.  At that point the "install" section of .travis.yml will be the same.  
The alerts ui e2e tests were removed for now until the work being done to 
stabilize them is complete.

The ES in-memory component starts up pretty fast so performance improved 
for the 3 tests by about 7 seconds.  Curious to hear what people think.

## 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 
  ```

- [x] 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)?
- [ ] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure 

[jira] [Commented] (METRON-1299) MetronError tests fail if hostname isn't set

2018-02-22 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/METRON-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16372902#comment-16372902
 ] 

ASF GitHub Bot commented on METRON-1299:


Github user merrimanr commented on the issue:

https://github.com/apache/metron/pull/924
  
+1 pending @cestella's approval.  Thanks @ottobackwards.


> MetronError tests fail if hostname isn't set
> 
>
> Key: METRON-1299
> URL: https://issues.apache.org/jira/browse/METRON-1299
> Project: Metron
>  Issue Type: Bug
>Affects Versions: 0.4.1
> Environment: openSUSE Tumbleweed 20171102, OpenJDK 1.8.0_144
>Reporter: Stuart Bertram
>Assignee: Otto Fowler
>Priority: Major
>
> If I run "mvn package" in the root Metron directory then compilation fails 
> because of a null reference in  
> {{./metron-platform/metron-common/src/test/java/org/apache/metron/common/error/MetronErrorTest.java}}.
>  This happens in {{getJSONObjectShouldReturnBasicInformation}} on line 56 
> because  {{errorJSON.get(Constants.ErrorFields.HOSTNAME.getName())}} is 
> assumed to return a string and the {{length()}} method is called on it. 
> Because the assert doesn't use a message then no obvious reason why it fails 
> is logged.
> The underlying problem is that 
> {{metron-platform/metron-common/src/main/java/org/apache/metron/common/error/MetronError.java}}
>  falls through to a {{catch}} block in {{addHostname()}} when 
> {{netAddress.getLocalHost().getHostName()}} exceptions with {{Name or service 
> not known}} for the host name.
> Setting a hostname that resolves is a build requirement that is out of 
> Metron's control, but if the code specifically handles the fact that it won't 
> always be retrieved then it seems problematic to have tests that assume it 
> works _and_ not make it clear what the failure is when it occurs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)