metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: [DISCUSS] SIDELOADING PARSERS: Archetype
Date Tue, 14 Mar 2017 22:16:55 GMT
That is the goal.
I don’t think I will replicate my original deployment stuff with ansible.

The drop package may be nar+.  I don’t think I want to put the
configurations in the nar.
So as far as what we have now… Nar will replace the uber, and we will still
do the assembly for the
configurations.

I’ll have a better idea as I get to that part.



On March 14, 2017 at 17:45:52, Kyle Richardson (kylerichardson2@gmail.com)
wrote:

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 <ottobackwards@gmail.com>
wrote:

> 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.
>

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