[DISCUSS] The various methods and incantations to spin up Metron

[Casey Stella <ce...@gmail.com>]

On another discuss thread, it was requested that we have some guidance
explicitly created to document the various methods and incantations to spin
up Metron.  I want to start this discussion here and the result, I propose,
will be placed in the top level README.md under a heading titled "Ways to
Start Metron in a Development Environment".

I propose for each component, we capture the following pieces of
information:

   - Description
   - Documentation link
   - When would you use it?
   - Is sufficient to use to test a PR against?
   - What kinds of changes would necessitate testing against this
   environment?
   - Caveats

I'll go first:

*Full Dev Vagrant*

   - Description
      - A single node vagrant machine with Metron installed via the
      management pack in Ambari.  This uses Centos 6.
   - Documentation Link
      -
      https://github.com/apache/incubator-metron/tree/master/metron-deployment/vagrant/full-dev-platform
   - When would you use it?
      - When you want a single node with a version of Metron installed with
      dummy sensors
   - Is sufficient to use to test a PR against?
      - Yes
   - What kinds of changes would necessitate testing against this
   environment?
      - Every PR should be tested against either this or quick-dev
   - Caveats:
      - Dummy sensors are used, not a real instance of bro or yaf or snort.


*Quick Dev Vagrant*


   - Description
      - A single node vagrant machine with Metron installed via the
      management pack in Ambari. This has some prepackaged components, so it's
      not starting from a bare centos OS.
   - Documentation Link
      -
      https://github.com/apache/incubator-metron/tree/master/metron-deployment/vagrant/quick-dev-platform
   - When would you use it?
      - When you want a single node with a version of Metron installed with
      dummy sensors and are working against master.
   - Is sufficient to use to test a PR against?
      - Yes
   - What kinds of changes would necessitate testing against this
   environment?
      - A change to the management pack code would require this to be
      rebuilt (see
      https://github.com/apache/incubator-metron/tree/master/metron-deployment/packaging/packer-build).
      The author of the commit who changed the management pack code
should update
      the packer image in atlas.
      - Any PR could be tested against quickdev
   - Caveats:
      - Dummy sensors are used, not a real instance of bro or yaf or snort.

Note here: I think
https://github.com/apache/incubator-metron/tree/master/metron-deployment/packaging/packer-build
should be more prescriptive and step-by-step for committers on how to
update the quickdev environment.  If I'm not an outlier on this, I'll make
a JIRA for it.

Ok, what am I missing?  Help me fill the rest of them out, please!

Best,

Casey