metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Date Fri, 10 Mar 2017 15:04:56 GMT
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

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