[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

[kylerichardson]

Github user kylerichardson commented on the issue:

https://github.com/apache/metron/pull/767
  
Absolutely, I've logged METRON-1210 for this.


---

[GitHub] metron issue #771: METRON-1204: UI does not time out after being idle, but s...

[merrimanr]

Github user merrimanr commented on the issue:

https://github.com/apache/metron/pull/771
  
The latest commit adds a "Session Expired" message on the login page and 
also applies the fix to the Management UI.  You will notice the 2 files look 
identical between metron-alerts and metron-config.  We might want to 
investigate a way to share components in the future.


---

[GitHub] metron pull request #773: METRON-1206: Make alerts UI conform to ops UI for ...

[merrimanr]

GitHub user merrimanr opened a pull request:

https://github.com/apache/metron/pull/773

METRON-1206: Make alerts UI conform to ops UI for install

## Contributor Comments
This PR is a precursor to 
[METRON-1207](https://issues.apache.org/jira/browse/METRON-1207) and 
[METRON-1208](https://issues.apache.org/jira/browse/METRON-1208).  The list of 
changes include:
- addition of a configuration file (as opposed to passing in arguments to 
the start script)
- a new init script for start/stop/restart operations
- updated assembly.xml to reflect shared expressjs directory structure
- changed port for Alerts UI to 4201 to avoid conflict with Management UI
- updated Alerts UI documentation

This can be tested by following the instructions in the README.  The 
previously mentioned follow-on PRs are also ready once this has been accepted.

## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [x] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [x] Have you ensured that the full suite of tests and checks have been 
executed in the root metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [x] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [x] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/merrimanr/incubator-metron METRON-1206

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/773.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #773


commit a8437e86ac36806cc9b4ed2c031509af13ba478a
Author: merrimanr 
Date:   2017-09-26T21:17:33Z

initial commit




---

[GitHub] metron issue #747: METRON-1175 [FEATURE-BRANCH] allow lazy loading of Bundle...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/747
  
Will be integrated with bundles pr


---

[GitHub] metron pull request #747: METRON-1175 [FEATURE-BRANCH] allow lazy loading of...

[ottobackwards]

Github user ottobackwards closed the pull request at:

https://github.com/apache/metron/pull/747


---

[GitHub] metron issue #761: METRON-1143 [FEATURE BRANCH] [NO-MERGE until PR#747] Mana...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/761
  
closing, will be landed down the line


---

[GitHub] metron pull request #761: METRON-1143 [FEATURE BRANCH] [NO-MERGE until PR#74...

[ottobackwards]

Github user ottobackwards closed the pull request at:

https://github.com/apache/metron/pull/761


---

[GitHub] metron issue #732: METRON-632: Added validation of "shew.enrichmentType" and...

[zezutom]

Github user zezutom commented on the issue:

https://github.com/apache/metron/pull/732
  
@cestella Could I possibly get this approved? Cheers


---

[GitHub] metron pull request #772: METRON-1209: Make stellar repl take logging proper...

[cestella]

GitHub user cestella opened a pull request:

https://github.com/apache/metron/pull/772

METRON-1209: Make stellar repl take logging properties, like other CLI apps 
in metron

## Contributor Comments
Right now we don't have an ability to specify the logging settings. We 
should make the REPL work just like the flat file loader or the MaaS CLI.

A note about the new maven project, this is just a place to keep the 3rd 
party extension we use in the unit tests.

## Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.  
Please refer to our [Development 
Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235)
 for the complete guide to follow for contributions.  
Please refer also to our [Build Verification 
Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview)
 for complete smoke testing guides.  


In order to streamline the review of the contribution we ask you follow 
these guidelines and ask you to double check the following:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to 
be created at [Metron 
Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
 
- [x] Does your PR title start with METRON- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?


### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [x] Have you ensured that the full suite of tests and checks have been 
executed in the root metron folder via:
  ```
  mvn -q clean integration-test install && build_utils/verify_licenses.sh 
  ```

- [x] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [x] Have you verified the basic functionality of the build by building 
and running locally with Vagrant full-dev environment or the equivalent?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered by building and verifying the site-book? If not then run 
the following commands and the verify changes via 
`site-book/target/site/index.html`:

  ```
  cd site-book
  mvn site
  ```

 Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up 
for your personal repository such that your branches are built there before 
submitting a pull request.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cestella/incubator-metron sideloading_bugs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/metron/pull/772.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #772


commit 5355e4c8443911103ee2e6430f181cb35a8b5863
Author: cstella 
Date:   2017-09-26T19:16:01Z

METRON-1209: Make stellar repl take logging properties, like other CLI apps 
in metron




---

[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

[mattf-horton]

Github user mattf-horton commented on the issue:

https://github.com/apache/metron/pull/767
  
Sure, but can we do that as a separate Jira?  We should advance the present 
version number promptly, since release 0.4.1 is published.


---

Re: [DISCUSS] Community meeting on Tuesday, Sept.23 10AM PST

[Laurens Vets]

11:30 won't work for me, but that's fine. I only had 1 comment on Otto's 
video: What happens when we have 2 parsers/sensors with the same name. 
If there's ever a parser/sensor repository, this might be an issue.


On 2017-09-25 17:38, Otto Fowler wrote:
11:30 your time.  Sorry I have to pick my kids up from school.  2:30 
mine.



On September 25, 2017 at 19:41:28, James Sirota (jsir...@apache.org) 
wrote:


Oh sorry, didn't notice that. Otto, when is a good time for you?

25.09.2017, 16:35, "zeo...@gmail.com" :
When is the meeting, given Otto mentioned he can't make 10am? Or did 
that

change

Jon

On Mon, Sep 25, 2017, 19:19 James Sirota  wrote:

 Great. Thank you, Otto. I would encourage everyone to watch it so 
that

we

 have constructive feedback for tomorrow and are able to arrive to a

decision


 Thanks,
 James

 25.09.2017, 08:27, "Otto Fowler" :
 > https://youtu.be/-ISycoP3TVA
 >
 > The video is short and simple. Hopefully it is what you are 
looking

for.

 >
 > On September 21, 2017 at 16:54:13, zeo...@gmail.com 
(zeo...@gmail.com)



 > wrote:
 >
 > I won't be able to make it and would really like to make sure 
there's

a
 > recording for this one, if possible. I'm unavailable until 
Thursday

of

 > next week, but not necessarily suggesting this gets moved.
 >
 > Jon
 >
 > On Thu, Sep 21, 2017, 15:04 Otto Fowler 

wrote:

 >
 >> I can’t make that time, can we make it later in the day?
 >>
 >> On September 21, 2017 at 11:40:37, James Sirota 
(jsir...@apache.org)

 >> wrote:
 >>
 >> https://hortonworks.webex.com/meet/jsirota
 > --
 >
 > Jon

 ---
 Thank you,

 James Sirota
 PPMC- Apache Metron (Incubating)
 jsirota AT apache DOT org

--

Jon


---
Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org

Re: feature branch bumps

[Nick Allen]

+1 I like it.  Thanks to both of your for working through this.  And thanks
to Otto for all the heavy lifting.  I'm willing to do whatever is needed to
help the process.

On Mon, Sep 25, 2017 at 8:52 PM, Matt Foley  wrote:

> Hi all,
> Otto and I had an off-line discussion about this, and we think we have a
> constructive suggestion that will allow chunking the feature branch to some
> extent, which will of course make it easier to review.  Otto is willing to
> make a series of PRs, each of which must be reviewed and committed to
> master before the next is submitted.  Please note that this plan may change
> somewhat, based on the PR reviews and any required work that comes out of
> them.
>
> The first PR will be just the “bundle” mechanism and the maven plugin.
> Both are adaptations from the Apache NiFi project, and have already been
> reviewed as part of PR# 530.  Review is acknowledged to be purely
> theoretical, and testing is based on the junit tests and integration
> tests.  We’ll add a simple integration test with a synthetic test jar
> containing a trivial Class, unrelated to parsers, invoked in a test case
> via reflection (hence needing no glue code).  After passing that level of
> review and testing, it would be committed, with an understanding that
> additional revisions might be required as the result of subsequent PR
> comments.  If bugs are found they shall be reported and fixed.
>
> The second PR will be the plumbing changes necessary to make parsers work
> efficiently with the bundle mechanism, and ONE parser to
> exercise/illustrate the functionality.  It will be either Bro or Snort, and
> tested in the full-dev environment.  The other parsers will be left alone,
> and continue to work correctly.  That’s a challenge; it means there will be
> some redundant code, some parallel functionality with different names that
> wouldn’t have been needed in the original all-or-nothing approach.  It will
> look ugly to have both mechanisms present at once.  But we will learn from
> this exactly what changes are needed, and why.  Both new and old unit tests
> will continue to work.
>
> The third PR will be the YAF parser, converted to the new model.  This
> will introduce the new Grok pattern loading mechanism for parsers.
>
> The fourth PR will be all the other parsers converted, and the old
> interfaces removed.  The ugly parallel code will be reduced to a single set
> of code.  Of course this could be split into multiple PRs if the community
> prefers, but it doesn’t seem necessary, since the incremental change to the
> existing parsers should be well understood by this point.
>
> The remaining pieces, the maven archetype, the REST and Stellar apis for
> management, and the UI, will be follow-on PRs.
>
> If we take this approach, it’s important to realize that Otto is
> committing to significant additional work.  We should do our best to work
> through the series of PRs promptly, and perhaps minimize other commits for
> a few days, to decrease the challenges of having the master branch change
> under him.
>
> What do you all think?
>
> Thanks,
> --Matt and Otto
>
>
> On 9/21/17, 11:53 AM, "Otto Fowler"  wrote:
>
> My thought was that in answering things in the wiki, it would build
> out the
> ‘guide’ there.  But I was just taking a stab at that.  I am open to
> whatever the group thinks would work best.
>
>
>
> On September 21, 2017 at 14:47:10, Nick Allen (n...@nickallen.org)
> wrote:
>
> > What I would like to do, and what it seems to me that we need to do (
> again I apologize if I am wrong ), is to catch up on the confluence and
> where things currently stand, and then move the discussion on from
> there.
>
> Perfect, thanks.  I think you are completely right.  I will review
> that in
> detail.
>
> Should I respond with questions in the comments of the Wiki or some
> other
> way?  Whatever works for you.
>
>
> On Thu, Sep 21, 2017 at 2:24 PM Otto Fowler 
> wrote:
>
> > Nick, thanks for taking the time to reply, I have no doubts about
> your
> > motivations and intent.  Hopefully we get through this point by point
> > stuff, which is always difficult on email.
> >
> >
> > https://cwiki.apache.org/confluence/display/METRON/
> Metron+Extension+System+and+Parser+Extensions
> >
> > This is my recent attempt at creating a framework for the review.  It
> > includes testing areas, review areas etc.  I have not received any
> feedback
> > on it so I have to assume that
> > you have not seen it.  My stated hope is that through questions
> about the
> > confluence I can address anything missing to make things reviewable,
> or
> > more reviewable. If you have reviewed it, and are just not referring
> to it,
> > I apologize.
> > Please take a look, and provide feedback so that I can address it
> there if
> > you have not.
> >

[GitHub] metron issue #762: METRON-1189: Add alert escalation to the Alerts UI

[iraghumitra]

Github user iraghumitra commented on the issue:

https://github.com/apache/metron/pull/762
  
+1


---

Re: [DISCUSS] Community meeting on Tuesday, Sept.23 10AM PST

[Otto Fowler]

Great!

Since it looks like I’ll be restating and refactoring things on master in
chunks this is still a ways off.  When I get to the ui/rest area I will
refactor to this.  When that time comes, I would like for us to talk about
having the concept of a local repository.

On top of what we just talked about….

We would install extensions to the repository in hdfs.  When you went to
install an extension, you could upload or pick from the repository.  We
would then get into the flow we were just talking about.  So the user would
only install the parser extensions they need.  Also, we could then
introduce remote repositories etc.

Another question is signing extensions.  We will have to think about that
before landing.


On September 26, 2017 at 07:06:23, Simon Elliston Ball (
si...@simonellistonball.com) wrote:

Hi Otto,

Sounds like we’re really getting somewhere there. I really like that idea.
If we have configs as a kind of default, which we can then use to bootstrap
any new sensor based on a parser from the bundles, that gives us the best
of every world.

Also, I’d agree with you that we should move all the parsers to the bundle
method (as you have in the code base) and that the UI should therefore
treat the parsers we supply as a project (CEF, bro, snort etc) as no
different from a parser an end user writes and bundles. The only area I
would say we want to distinguish, as you already have I believe, is the
base parsers (Java, Grok) since those would be a start point for
inheritance.

If we can get the configs as default bootstrap rather than source of truth,
I think we will have a great system. Let me know if there is anything
around that I can help with on the implementation side.

Simon


On 26 Sep 2017, at 11:53, Otto Fowler  wrote:

Hi Simon

1.  At this moment, in the unreviewed PR ( although this kind of counts ;)
) it will overwrite.
2. You just create a new sensor, based on that type and give it a different
name, same as you would now.  You would have to start each configuration
from nothing however, because the UI doesn’t copy an existing sensor -or-
copy from the extension default ( where they exist )

More on 1.  I have mentioned in the PR and other threads about these
changes being the start of a lifecycle for parsers/sensors.  The idea being
that you install the parsers, and their default configurations but doesn’t
create the sensor by default as we do now ( both in master and fb ), and
then when you create a parser, it copies the default configuration, using
that to pre- populate the configuration ui. Thus, the install would never
touch the deployed configurations.  I did not go so far as to implement
that, but I think that is where we can go.  Short of that, I can change the
extensions to not install default configs or not to overwrite if they
exist.   BTW.  The issue you are speaking about I believe is present in
metron in general before this change.  If someone could clarify the upgrade
stuff in ambari it would help.  We don’t check if there are already
configurations in zookeeper ever before pushing configurations out.

This also brings me back to my discuss question from the other day:  The
extension list you see in the demo, only has the user installed parser
extensions, not the system ( metron ) ones, like bro, yaf, snort etc.  Thus
they are not managed the same way, and they are not registered the same way
with the default configurations in a separate place.

I think what we want is all parsers installed as extensions, not to install
the parsers as sensors by default as we do now, and the configuration ui to
use the default from the extension registration when creating new.  I think
the ‘demo’ system should be a separate ambari install all together. IE> The
install of bro, snort, the dashboard, es templates.

We are now a long ways off from landing the UI pr.  I was always expecting
refactoring around the configuration management and install part, so
please, let me know what you think and I can take a shot at it.  Don’t
forget about irc.




On September 26, 2017 at 05:17:32, Simon Elliston Ball (
si...@simonellistonball.com) wrote:

Hi Otto,

This is a great demo, nice and clear, many thanks.

Two questions remain for me:

1. how I would change configuration outside of the bundle? i.e. I install a
bundle and that gives me enrichment and indexing config, but I then want to
tune indexing for the characteristics of the actual sensor, or I want to
add use cases in enrichment which are customised to my org, what happens if
I update the bundle, does it overwrite the zookeeper config changes? Do I
have to add all my enrichment config in the bundle? That would be an
absolute blocker for SOC ops users who do not have access to maven for
example and would render the management ui null and void.
2. At the moment it seems bundle implies sensor. How would I have a parser
(e.g. CEF parser) which was used against multiple topics (i.e. one parser
bundle for a data type, 

Re: [DISCUSS] Community meeting on Tuesday, Sept.23 10AM PST

[Simon Elliston Ball]

Hi Otto, 

Sounds like we’re really getting somewhere there. I really like that idea. If 
we have configs as a kind of default, which we can then use to bootstrap any 
new sensor based on a parser from the bundles, that gives us the best of every 
world. 

Also, I’d agree with you that we should move all the parsers to the bundle 
method (as you have in the code base) and that the UI should therefore treat 
the parsers we supply as a project (CEF, bro, snort etc) as no different from a 
parser an end user writes and bundles. The only area I would say we want to 
distinguish, as you already have I believe, is the base parsers (Java, Grok) 
since those would be a start point for inheritance. 

If we can get the configs as default bootstrap rather than source of truth, I 
think we will have a great system. Let me know if there is anything around that 
I can help with on the implementation side.

Simon


> On 26 Sep 2017, at 11:53, Otto Fowler  wrote:
> 
> Hi Simon
> 
> 1.  At this moment, in the unreviewed PR ( although this kind of counts ;) ) 
> it will overwrite.
> 2. You just create a new sensor, based on that type and give it a different 
> name, same as you would now.  You would have to start each configuration from 
> nothing however, because the UI doesn’t copy an existing sensor -or- copy 
> from the extension default ( where they exist )
> 
> More on 1.  I have mentioned in the PR and other threads about these changes 
> being the start of a lifecycle for parsers/sensors.  The idea being that you 
> install the parsers, and their default configurations but doesn’t create the 
> sensor by default as we do now ( both in master and fb ), and then when you 
> create a parser, it copies the default configuration, using that to pre- 
> populate the configuration ui. Thus, the install would never touch the 
> deployed configurations.  I did not go so far as to implement that, but I 
> think that is where we can go.  Short of that, I can change the extensions to 
> not install default configs or not to overwrite if they exist.   BTW.  The 
> issue you are speaking about I believe is present in metron in general before 
> this change.  If someone could clarify the upgrade stuff in ambari it would 
> help.  We don’t check if there are already configurations in zookeeper ever 
> before pushing configurations out.
> 
> This also brings me back to my discuss question from the other day:  The 
> extension list you see in the demo, only has the user installed parser 
> extensions, not the system ( metron ) ones, like bro, yaf, snort etc.  Thus 
> they are not managed the same way, and they are not registered the same way 
> with the default configurations in a separate place.
> 
> I think what we want is all parsers installed as extensions, not to install 
> the parsers as sensors by default as we do now, and the configuration ui to 
> use the default from the extension registration when creating new.  I think 
> the ‘demo’ system should be a separate ambari install all together. IE> The 
> install of bro, snort, the dashboard, es templates. 
> 
> We are now a long ways off from landing the UI pr.  I was always expecting 
> refactoring around the configuration management and install part, so please, 
> let me know what you think and I can take a shot at it.  Don’t forget about 
> irc.
> 
> 
> 
> 
> On September 26, 2017 at 05:17:32, Simon Elliston Ball 
> (si...@simonellistonball.com ) wrote:
> 
>> Hi Otto,  
>> 
>> This is a great demo, nice and clear, many thanks.  
>> 
>> Two questions remain for me: 
>> 
>> 1. how I would change configuration outside of the bundle? i.e. I install a 
>> bundle and that gives me enrichment and indexing config, but I then want to 
>> tune indexing for the characteristics of the actual sensor, or I want to add 
>> use cases in enrichment which are customised to my org, what happens if I 
>> update the bundle, does it overwrite the zookeeper config changes? Do I have 
>> to add all my enrichment config in the bundle? That would be an absolute 
>> blocker for SOC ops users who do not have access to maven for example and 
>> would render the management ui null and void. 
>> 2. At the moment it seems bundle implies sensor. How would I have a parser 
>> (e.g. CEF parser) which was used against multiple topics (i.e. one parser 
>> bundle for a data type, multiple sensors based on multiple topics feeding 
>> that type)? 
>> 
>> Really keen to get this in as an extension mechanism, as I think it will be 
>> a huge help to people developing custom parsers, but I really want to make 
>> sure it will not clobber the use cases people add with enrichment config in 
>> particular.  
>> 
>> Simon 
>> 
>> > On 25 Sep 2017, at 16:27, Otto Fowler > > > wrote: 
>> >  
>> > https://youtu.be/-ISycoP3TVA  
>> >  
>> > The video is short and simple. 

Re: [DISCUSS] Community meeting on Tuesday, Sept.23 10AM PST

[Simon Elliston Ball]

Hi Otto, 

This is a great demo, nice and clear, many thanks. 

Two questions remain for me:

1. how I would change configuration outside of the bundle? i.e. I install a 
bundle and that gives me enrichment and indexing config, but I then want to 
tune indexing for the characteristics of the actual sensor, or I want to add 
use cases in enrichment which are customised to my org, what happens if I 
update the bundle, does it overwrite the zookeeper config changes? Do I have to 
add all my enrichment config in the bundle? That would be an absolute blocker 
for SOC ops users who do not have access to maven for example and would render 
the management ui null and void.
2. At the moment it seems bundle implies sensor. How would I have a parser 
(e.g. CEF parser) which was used against multiple topics (i.e. one parser 
bundle for a data type, multiple sensors based on multiple topics feeding that 
type)?

Really keen to get this in as an extension mechanism, as I think it will be a 
huge help to people developing custom parsers, but I really want to make sure 
it will not clobber the use cases people add with enrichment config in 
particular. 

Simon

> On 25 Sep 2017, at 16:27, Otto Fowler  wrote:
> 
> https://youtu.be/-ISycoP3TVA
> 
> The video is short and simple.  Hopefully it is what you are looking for.
> 
> 
> On September 21, 2017 at 16:54:13, zeo...@gmail.com (zeo...@gmail.com)
> wrote:
> 
> I won't be able to make it and would really like to make sure there's a
> recording for this one, if possible. I'm unavailable until Thursday of
> next week, but not necessarily suggesting this gets moved.
> 
> Jon
> 
> On Thu, Sep 21, 2017, 15:04 Otto Fowler  wrote:
> 
>> I can’t make that time, can we make it later in the day?
>> 
>> 
>> On September 21, 2017 at 11:40:37, James Sirota (jsir...@apache.org)
>> wrote:
>> 
>> https://hortonworks.webex.com/meet/jsirota
>> 
> -- 
> 
> Jon