Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

METRON-1741 Move REPL Port of Profiler to Separate Project #1170

Conversation

nickwallen
Copy link
Contributor

@nickwallen nickwallen commented Aug 21, 2018

This separates out the Profiler code specific to the port which runs in the Stellar REPL into its own project. This also creates a separate tarball and RPM for the Profiler in the Stellar REPL.

Since there will soon be 3 ports of the Profiler; Storm, the REPL, and Spark, I want to separate out the code base so that it cleanly delineate which code is used by which port. Soon we should have the following projects.

  • metron-profiler-common: All of the common Profiler code shared amongst each port.
  • metron-profiler-spark: Profiler on Spark
  • metron-profiler-repl: Profiler on the Stellar REPL
  • metron-profiler-storm: Profiler on Storm
  • metron-profiler-client: The client code like PROFILE_GET, etc.

This is dependent on the following PRs . By filtering on the last two commits, this PR can be reviewed before the others are reviewed and merged.

Testing

  1. Spin-up the development environment.

  2. Validate the development environment by ensuring alerts are visible within the Alerts UI and that the Metron Service Check in Ambari passes.

  3. Launch the REPL and follow the instructions in the Profiler README to create and execute a profile in the REPL.

  4. Follow the instructions in the README to deploy the same profile in Storm. Ensure that you can retrieve values from HBase using PROFILE_GET.

Pull Request Checklist

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

@merrimanr
Copy link
Contributor

I ran this up in full dev and went through the testing instructions. Everything worked great. +1

@nickwallen
Copy link
Contributor Author

Thanks for the review! This has been merged into the feature branch.

@nickwallen nickwallen closed this Sep 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants