METRON-2016: Parser aggregate groups should be persisted and available through REST

[merrimanr]

Contributor Comments

This PR adds a REST endpoint that manages parser groups in the global config. The endpoint exposes CRUD operations for a new SensorParserGroup object used to store a group name, description and sensor list.

Changes Included

• SensorParserGroup type was added.
• Method added to ParserConfigurations for converting the objects stored in the global config to an array of SensorParserGroup objects.
• REST classes added to support CRUD operations (SensorParserGroupController, SensorParserGroupService, SensorParserGroupServiceImpl).
• Logic added to the existing StormAdminServiceImpl and StormStatusServiceImpl classes for converting a SensorParserGroup to the corresponding Storm topology name.
• The parser_commands.py Ambari mpack script was updated to sort the sensors before starting/stopping topologies. This is needed so that both Ambari and REST can correctly generate a topology name from a list of sensors.
• Slightly refactored ParserTopologyCLI to use a constant sensor separator.
• Added tests and javadocs where appropriate.

Changes NOT Included

• The ParserTopologyCLI still expects a comma-separated list of sensors when starting a topology. The concept of a SensorParserGroup is limited to REST at this point. We could add group name support to ParserTopologyCLI but I don't see a requirement. If desired I believe this should be a follow on.

Testing

This has been tested in full dev.

1. Spin up full dev and verify data is flowing to ES.
2. Create a sensor group:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"description": "group1 description",
"name": "group1",
"sensors": [
"bro","snort","yaf"
]
}' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

A 201 status with the new group should be returned.

3. Create another group:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"description": "group2 description",
"name": "group2",
"sensors": [
"jsonMap","jsonMapQuery"
]
}' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

4. Get all groups and verify both groups are returned:

curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

5. The groups should also be visible in the global config:

curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/global/config'

6. Verify a group can be retrieved by name:

curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/sensor/parser/group/group1'

7. Try to create a new group with a sensor that is already contained in another group:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"description": "group3 description",
"name": "group3",
"sensors": [
  "bro"
]
}' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

You should get an error with an obvious and descriptive message.

8. Try to create a new group with a sensor that does not exist:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"description": "group3 description",
"name": "group3",
"sensors": [
  "test"
]
}' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

You should get an error with an obvious and descriptive message.

9. Try to create a group with an empty sensor list:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"description": "group3 description",
"name": "group3",
"sensors": [
]
}' 'http://user:password@node1:8082/api/v1/sensor/parser/group'

You should get an error with an obvious and descriptive message.

10. Delete a group:

curl -X DELETE --header 'Accept: */*' 'http://user:password@node1:8082/api/v1/sensor/parser/group/group2'

You should get a 200 and the group should no longer be in the global config.

11. Try to delete the same group again:

curl -X DELETE --header 'Accept: */*' 'http://user:password@node1:8082/api/v1/sensor/parser/group/group2'

You should get a 404 since the group no longer exists.

12. Navigate to Ambari > Metron > Configs > Parsers and change "Metron Parsers" to "yaf,bro,snort",squid. This will test the Ambari change to ensure sensors are sorted in the job name and multiple topologies are still supported. Restart the Parser component.
13. Verify that both the bro__snort__yaf and squid topologies are running with the Storm UI.
14. Get the topology status with REST for group1 that contains the bro, snort and yaf sensors:

curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/storm/group1'

An ACTIVE status should be returned.

15. Verify the group1 topology can be successfully stopped with REST:

curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/storm/parser/stop/group1?stopNow=true'

16. Verify the group1 topology can be successfully started with REST:

curl -X GET --header 'Accept: application/json' 'curl -X GET --header 'Accept: application/json' 'http://user:password@node1:8082/api/v1/storm/parser/start/group1''

Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines 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:

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX 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)?

For code changes:

• 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:

  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?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

• 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 that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

[nickwallen]

Looking good. Just two small nits.

[nickwallen]

+1 by inspection. Many thanks.