Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/916
@as22323 Let me first say that this is a nice piece of work. You've
followed all the existing patterns and your contribution looks solid.
But ultimately I am +0 on this. I want others to speak up should they see
value in this, but I'd argue that this should not be merged. Please let me
explain my reasoning.
**Support Burden**
IMHO, the 'surface area' to support in Metron has always been too large.
We as a community spend too much time supporting non-core functionality, which
impedes our progress in delivering features targeted toward the cybersecurity
use case.
One key example of this are the multiple different deployment targets that
we support. This has been a difficult and time consuming support task over the
history of the project. I've done plenty of work on this myself.
Coalescing Metron installation around the MPack was a major step forward
for us. This was intended to help remove some of that support burden. With
the MPack, much of that burden is shifted to Ambari.
For example, with everything in Metron today, you can stand-up a single
node in AWS and use the Mpack to install Metron. It is not as "push button"
simple as your contribution here, but it is "good enough" considering the
resources we have in the community today.
**Uncommon Use Case**
We should also considering that running Metron on a single node is a recipe
for a horrible user experience. It should only be run on a single node for
development purposes, which is something that we already do support. I would
not recommend that anyone run Metron on a single node for any other purpose.
--
I'd prefer not too add to our ongoing support burden by merging this PR.
What you've done is a great contribution and I'd love to see you publicly share
and support this as a separate project, outside of Apache Metron, going forward.
If others agree or disagree with my reasoning, please do feel free to share.
---
