[DISCUSS] Overcoming developer inertia when spinning up new environments

[Ryan Merriman <me...@gmail.com>]

I want to revisit the idea of providing an alternative container-based
approach (Docker, Kubernetes, etc) to spinning up Metron that is faster and
uses less resources (a "Metron light").  This would provide a way for
reviewers to more quickly review and test out changes.  Full dev with
ansible will still serve it's purpose, this would just be another tool for
cases where full dev is not the best fit.

This would be a new non-trivial module that will need to be maintained.
There have been discussions in the past that resulted in the community not
wanting to maintain another installation path.  However it has been a while
since we had those discussions and Metron is now more mature.  We would
also be able to leverage the work already being done in
https://issues.apache.org/jira/browse/METRON-1352 to unify the integration
testing infrastructure.

There are other potential use cases for this too.  It could be expanded to
provide a demo environment for exploring the UIs and Metron API.  Providing
container support for Metron could also be the beginning of a broader cloud
deployment strategy.

Is this something we want to explore?  What would the requirements be?

Re: [DISCUSS] Overcoming developer inertia when spinning up new environments

[Otto Fowler <ot...@gmail.com>]

A bus factor of > 1?

One main requirement would be that the implementation of the deployment has
to be done and documented
in such a way that it is maintainable.  I *think* if this was done in
chucks, and under review and better yet
more collaboration, that would be possible.

Another would be some kind of CI testing for regression.


On December 18, 2017 at 18:46:10, Ryan Merriman (merrimanr@gmail.com) wrote:

I want to revisit the idea of providing an alternative container-based
approach (Docker, Kubernetes, etc) to spinning up Metron that is faster and
uses less resources (a "Metron light"). This would provide a way for
reviewers to more quickly review and test out changes. Full dev with
ansible will still serve it's purpose, this would just be another tool for
cases where full dev is not the best fit.

This would be a new non-trivial module that will need to be maintained.
There have been discussions in the past that resulted in the community not
wanting to maintain another installation path. However it has been a while
since we had those discussions and Metron is now more mature. We would
also be able to leverage the work already being done in
https://issues.apache.org/jira/browse/METRON-1352 to unify the integration
testing infrastructure.

There are other potential use cases for this too. It could be expanded to
provide a demo environment for exploring the UIs and Metron API. Providing
container support for Metron could also be the beginning of a broader cloud
deployment strategy.

Is this something we want to explore? What would the requirements be?