You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by nickwallen <gi...@git.apache.org> on 2018/04/04 17:03:02 UTC

[GitHub] metron issue #916: METRON-1434 - Ability to deploy Metron full dev as a sing...

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.


---