metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Richardson <>
Date Tue, 14 Mar 2017 21:45:43 GMT
Could the archetype be deployment agnostic? It's probably a little
simplistic due to all the configs, but I like the NAR solution of simply
drop in lib and restart services.

On Fri, Mar 10, 2017 at 10:04 AM, Otto Fowler <>

> As previously discussed here, I have been working on side loading of
> parsers.  The goals of this work are:
> * Make it possible of developers to create, maintain and deploy parsers
> outside of the Metron code tree and not have to fork
> * Create maven archetype support for developers of parsers
> * Introduce a parser ‘lifecycle’ to support multiple instances and
> configurations, states of being installed, under configuration, and
> deployed
> etc.
> I would like to have some discussion based on where I am after rebasing
> onto METRON-671 which revamps deployment to be totally ambari based.
> Maven Parser Archetype
> I have an archetype for creating a metron parser module project.
> When running the archetype you get:
> * a parser project, with all the names etc filled out based on the
> archetype parameters
> * a rudimentary sample parser ( that needs improvement )
> * a metron-deployment ansible project that will deploy the parser
> * a script to run the deployment and deploy it to a locally running quick
> or full dev
> * It is still Monit based - no ambari integration
> I am not sure if this is worth landing right now, until other issues are
> sorted out:
> * the thinning of the jars and ‘extension’ packaging/loading
> * ambari deployment - will people be deploying their jars into ‘our’ ambari
> deployment or into their own ambari service dependent on ours?
> I am just not sure about having an archetype that is going to be obsoleted.
> What I would like to do is save the archetype for when that stuff is
> sorted.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message