[
https://issues.apache.org/jira/browse/METRON-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056465#comment-16056465
]
ASF GitHub Bot commented on METRON-777:
---------------------------------------
Github user mmiklavc commented on a diff in the pull request:
https://github.com/apache/metron/pull/530#discussion_r123090723
--- Diff: metron-analytics/metron-maas-service/README.md ---
@@ -138,7 +138,7 @@ Now that we have a deployed model, let's adjust the
configurations for the Squid
* Edit the squid parser configuration at
`$METRON_HOME/config/zookeeper/parsers/squid.json` in your favorite text editor
and add a new FieldTransformation to indicate a threat alert based on the model
(note the addition of `is_malicious` and `is_alert`):
```
{
- "parserClassName": "org.apache.metron.parsers.GrokParser",
+ "parserClassName": "org.apache.metron.parsers.grok.GrokParser",
--- End diff --
I noticed GrokParser and CSVParser remain in the metron-parsers project. Is
there a general rule of thumb for what would be considered general vs what
should become a parser-extension? My intuition here says that since Grok and
CSV are more abstract concepts, they're kept in metron-parsers while more
concrete implementations of those types are realized as extensions, e.g. squid
is Grok. Is that your thinking here as well?
> Create a plugin system for Metron based on 'NAR'
> ------------------------------------------------
>
> Key: METRON-777
> URL: https://issues.apache.org/jira/browse/METRON-777
> Project: Metron
> Issue Type: New Feature
> Reporter: Otto Fowler
> Assignee: Otto Fowler
>
> The success of the Metron project will be greatly dependent on community
> participation, and with that the ability to adapt and extend Metron without
> having to maintain a fork of the project.
> As organizations and individuals look to extend the Metron system with custom
> parsers, enrichments, and stellar functions that may be proprietary in
> nature, the ability to develop and deploy these extensions outside the Metron
> code base is critically important.
> To that end, and after community discussion and proposal we create or
> formalize the 'plugin' development story in Metron.
> The proposal is to adapt the Apache Nifi NAR system for use in Metron. This
> will provide the system with:
> * archetype(s) for developer projects and independent development
> * defined packaging and metadata for 'plugin' products
> * loading and instantiation with classloader isolation capabilities
> * removing the necessity for shading plugin jars
> These capabilities will also enable other features, such as plugin lifecycle,
> plugin configuration+redeployment, and other things.
> The plugin archetypes and their installation will be a followon
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
