metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nickwallen <...@git.apache.org>
Subject [GitHub] metron issue #916: METRON-1434 - Ability to deploy Metron full dev as a sing...
Date Wed, 04 Apr 2018 17:03:02 GMT
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.


---

Mime
View raw message