Re: [DISCUSS] Deprecating MySQL

[Ali Nazemian]

Great feature to move to LDAP integration and hopefully Ranger
integration afterwards. Does it need to support LDAP and AD separately?

Cheers,
Ali

On Sat, Nov 17, 2018 at 3:29 AM Otto Fowler  wrote:

> I would like to understand the work required to move our JDBC support ( or
> adapt the current support to the abstraction ) to /contrib.
> We could default and only officially support LDAP, but have the /contrib (
> or /extension_examples ) have a “this is how you would support jdbc for
> auth “ project.
>
>
>
> On November 15, 2018 at 15:01:10, Michael Miklavcic (
> michael.miklav...@gmail.com) wrote:
>
> Yes, makes sense. +1 to that.
>
> On Thu, Nov 15, 2018 at 12:54 PM James Sirota  wrote:
>
> > To clarify my position, I don't have a problem with mySql or any other
> > projects relying on it. mySql in itself is not an issue. What I don't
> > want is for a customer to be presented with an option to chose and
> > configure two options for authenticating the UI, which I think is
> > needless. It adds complexity for not much value. Since LDAP is clearly
> > the better way to go that should be what we support without explicitly
> > giving a user an option to switch to JDBC. A user can still do so by
> > extending our abstractions if that is what they chose to do, but this
> would
> > not be officially supported by us. We would not be providing a config or
> > an mPack to do this. A user would have to do it on their own.
> >
> > James
> >
> >
> >
> > 15.11.2018, 12:15, "Michael Miklavcic" :
> > > Incidentally, even without the Metron piece in the picture, what is the
> > > answer for Ambari's database dependency? Which uses a SQL data store.
> > Does
> > > this actually solve the problem of "customers won't install Metron bc
> SQL
> > > store?" or are there other issues we need to address?
> > >
> > > On Thu, Nov 15, 2018 at 9:30 AM James Sirota 
> wrote:
> > >
> > >> Hi Guys,
> > >>
> > >> My opinion on this, as is with Knox SSO, is that the code should be
> > >> pluggable to support JDBC, but we should not continue to support the
> > >> concrete implementation and expose it to users via a setting. This is
> a
> > >> fairly minor feature and the added complexity of supporting switching
> > >> between JDBC and LDAP is simply not worth it. We need to strike a
> > balance
> > >> between ease of use and capabilities/extensibility. For features that
> > are
> > >> worth it such as with analytics and stream processing, the extra
> > capability
> > >> is worth the added complexity in configuration. But for this, it is
> > not.
> > >> So let's keep JDBC around for a release to allow users to migrate to
> > LDAP,
> > >> deprecate it, and move on.
> > >>
> > >> Thanks,
> > >> James
> > >>
> > >> 13.11.2018, 16:03, "Simon Elliston Ball"  > >:
> > >> > We went over the hbase user settings thing on extensive discussions
> > at
> > >> the time. Storing an arbitrary blob of JSON which is only ever
> > accessed by
> > >> a single key (username) was concluded to be a key value problem, not a
> > >> relational problem. Hbase was concluded to be massive overkill as a
> key
> > >> value store in this usecase, unless it was already there and ready to
> > go,
> > >> which in the case of Metron, it is, for enrichments, threat intel and
> > >> profiles. Hence it ended up in Hbase, as a conveniently present data
> > store
> > >> that matched the usage patterns. See
> > >>
> >
>
> https://lists.apache.org/thread.html/145b3b8ffd8c3aa5bbfc3b93f550fc67e71737819b19bc525a2f2ce2@%3Cdev.metron.apache.org%3E
> > >> and METRON-1337 for discussion.
> > >> >
> > >> > Simon
> > >> >
> > >> >> On 13 Nov 2018, at 18:50, Michael Miklavcic <
> > >> michael.miklav...@gmail.com> wrote:
> > >> >>
> > >> >> Thanks for the write up Simon. I don't think I see any major
> > problems
> > >> with
> > >> >> deprecating the general sql store. However, just to clarify, Metron
> > >> does
> > >> >> NOT require any specific backing store. It's 100% JPA, which means
> > >> anything
> > >> >> that can be configured with the Spring properties we expose. I
> think
> > >> the
> > >> >> most opinionated thing we do there is ship an extremely basic table
> > >> >> creation script for h2 and mysql as a simple example for schema. As
> > an
> > >> >> example, we simply use H2 in full dev, which is entirely in-memory
> > and
> > >> spun
> > >> >> up automatically from configuration. The recent work by Justin Leet
> > >> removes
> > >> >> the need to use a SQL store at all if you choose LDAP -
> > >> >> https://github.com/apache/metron/pull/1246. I'll let him comment
> > >> further on
> > >> >> this, but I think there is one small change that could be made via
> a
> > >> toggle
> > >> >> in Ambari that would even eliminate the user from seeing JDBC
> > settings
> > >> >> altogether during install if they choose LDAP. Again, I think I'm
> on
> > >> board
> > >> >> with deprecating the SQL backing store as I pointed this out on the
> > >> Knox
> > >> >> thread as well, but I 

Re: [DISCUSS] Deprecate split-join enrichment topology in favor of unified enrichment topology

[Ali Nazemian]

Hi,

One thing to point out here is there were a few timestamp fields that
exist for Split-join enrichment topology that haven't been made to the
unified one. For example, there is no threat intel bolt timestamp. There
might be some SLA related use cases regarding these timestamp fields that
might be nice to have before depreciation of the split-join one. Generally
speaking, makes sense to deprecate split-join topology, though.

Cheers,
Ali

On Fri, Nov 16, 2018 at 3:40 AM James Sirota  wrote:

> This is excellent work, Mike and long overdue.  Thanks for doing this
>
> 05.11.2018, 16:46, "Michael Miklavcic" :
> > The PR has now been merged into master and closed.
> >
> > https://issues.apache.org/jira/browse/METRON-1855
> >
> > On Sat, Nov 3, 2018 at 6:47 PM Michael Miklavcic <
> > michael.miklav...@gmail.com> wrote:
> >
> >>  PR is out here - https://github.com/apache/metron/pull/1252
> >>
> >>  I made the unified enrichment topology the new default and marked the
> >>  split-join topology as deprecated in various parts of the
> documentation. I
> >>  think we should have a release with the deprecation notes and new
> default
> >>  and then move to remove split-join entirely shortly thereafter.
> >>
> >>  Best,
> >>  Mike
> >>
> >>  On Fri, Nov 2, 2018 at 5:47 AM Mohan Venkateshaiah <
> >>  mvenkatesha...@hortonworks.com> wrote:
> >>
> >>>  +1 (non-binding)
> >>>
> >>>  Thanks
> >>>  Mohan DV
> >>>
> >>>  On 11/2/18, 3:29 PM, "zeo...@gmail.com"  wrote:
> >>>
> >>>  +1 totally agree.
> >>>
> >>>  Jon
> >>>
> >>>  On Fri, Nov 2, 2018, 1:31 AM Anand Subramanian <
> >>>  asubraman...@hortonworks.com>
> >>>  wrote:
> >>>
> >>>  > Piling on my +1 (non-binding) as well.
> >>>  >
> >>>  > On 11/2/18, 4:41 AM, "Ryan Merriman" 
> wrote:
> >>>  >
> >>>  > +1
> >>>  >
> >>>  > On Thu, Nov 1, 2018 at 5:38 PM Casey Stella  >>>  >
> >>>  > wrote:
> >>>  >
> >>>  > > +1
> >>>  > > On Thu, Nov 1, 2018 at 18:34 Nick Allen 
> >>>  wrote:
> >>>  > >
> >>>  > > > +1
> >>>  > > >
> >>>  > > > On Thu, Nov 1, 2018, 6:27 PM Justin Leet <
> >>>  justinjl...@gmail.com>
> >>>  > wrote:
> >>>  > > >
> >>>  > > > > +1, I haven't seen any case where the split-join topology
> >>>  isn't
> >>>  > made
> >>>  > > > > obsolete by the unified topology.
> >>>  > > > >
> >>>  > > > > On Thu, Nov 1, 2018 at 6:17 PM Michael Miklavcic <
> >>>  > > > > michael.miklav...@gmail.com> wrote:
> >>>  > > > >
> >>>  > > > > > Fellow Metronians,
> >>>  > > > > >
> >>>  > > > > > We've had the unified enrichment topology around for a
> >>>  number
> >>>  > of
> >>>  > > months
> >>>  > > > > > now, it has proved itself stable, and there is yet to
> >>>  be a
> >>>  > time that
> >>>  > > I
> >>>  > > > > have
> >>>  > > > > > seen the split-join topology outperform the unified
> >>>  one. Here
> >>>  > are
> >>>  > > some
> >>>  > > > > > simple reasons to deprecate the split-join topology.
> >>>  > > > > >
> >>>  > > > > > 1. Unified topology performs better.
> >>>  > > > > > 2. The configuration, especially for performance
> >>>  tuning is
> >>>  > much,
> >>>  > > > much
> >>>  > > > > > simpler in the unified model.
> >>>  > > > > > 3. The footprint within the cluster is smaller.
> >>>  > > > > > 4. One of the first activities for any install is
> >>>  that we
> >>>  > spend
> >>>  > > time
> >>>  > > > > > instructing users to switch to the unified topology.
> >>>  > > > > > 5. One less moving part to maintain.
> >>>  > > > > >
> >>>  > > > > > I'd like to recommend that we deprecate the split-join
> >>>  > topology and
> >>>  > > > make
> >>>  > > > > > the unified enrichment topology the new default.
> >>>  > > > > >
> >>>  > > > > > Best,
> >>>  > > > > > Mike
> >>>  > > > > >
> >>>  > > > >
> >>>  > > >
> >>>  > >
> >>>  >
> >>>  >
> >>>  > --
> >>>
> >>>  Jon Zeolla
>
> ---
> Thank you,
>
> James Sirota
> PMC- Apache Metron
> jsirota AT apache DOT org
>
>

-- 
A.Nazemian

Re: [DISCUSS] Authorization for Configuration

[Ali Nazemian]

Hi Justin,

By configuration do you mean the sensor related configurations only? Are
you limiting the scope of this activity to the management-UI or also
Alert-UI as well? For example, defining different roles (pre-defined
or customizable) and the fine-grained integration with Ranger?

Cheers,
Ali

On Thu, Nov 15, 2018 at 1:16 AM Justin Leet  wrote:

> Hi all,
>
> Sorry for the second copy of this email, I forgot the  [DISCUSS] tag on the
> original.  Otherwise, this has the same content.
>
> Right now, our various configs can be modified by anyone with access to the
> various scripts. I'd like to start a discussion around building out some
> authorization to be able to add some more fine grained controls around
> this.
>
> Other projects have some variants on how to accomplish this.  Typically,
> this follows a pattern of calling out to a interface/class that takes in
> the operation and context (user and other info) and returns true/false if
> something is authorized.
>
> In my mind, what we would need out of this is
>
>- Ability to apply fine grained permissions
>- The various scripts and UI should flow this authorization framework.
>I believe most (if not all) of our configuration flows through
>ConfigurationsUtils.  Anything that doesn't should either be hooked in
> or
>refactored to flow through the same codepaths.
>- Pluggability. We shouldn't force only one authorizer.
>
> In particular, I'm proposing we use Apache Ranger
>  as a supported authorization framework,
> implementing it alongside the authorization framework to validate what we
> build. In my mind, the main catch with Ranger is that, based on my
> understanding, we won't be able to restrict users with direct access to
> ZooKeeper via it's CLI (e.g. Ranger can't mirror it's ACLs down into ZK's
> ACLs).  I believe this is a reasonable restriction, especially as the
> management UI gets improved to handle more of the configuration burden and
> the number of users with access to ZK CLI begins to decrease.  Users can
> still add ZK ACLs separately to enforce that access there.
>
> For anyone not familiar with Ranger, essentially you build a plugin that
> hooks into the existing component's authorization framework (e.g. for
> Storm, the plugin runs through the IAuthorizer
> <
> https://storm.apache.org/releases/1.2.2/javadocs/org/apache/storm/security/auth/IAuthorizer.html
> >
> interface,
> for Yarn it runs through YarnAuthorizationProvider
> <
> http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/apidocs/org/apache/hadoop/yarn/security/YarnAuthorizationProvider.html
> >).
> Additionally, Ranger provides auditing capabilities for this authorization
> and has plugins for a good portion of our stack already (so users can
> already setup ACLs on HDFS, Storm, etc.). Checkout the Ranger Github
>  for a list of the plugins they have
> built in.
>
> What this means for Metron is building out an authorization setup similar
> to Storm or Yarn or whatever we choose. We'll want this anyway, to allow
> our solution to be pluggable.  At that point, we build an implementation of
> the authorizer compatible with Ranger along with the plugin.
>
> I think this could probably be a fairly small feature branch, which I'm
> suggesting primarily to do the Ranger implementation alongside the general
> authorization work to validate what's being built.  I think the main
> tasking would be something similar to:
>
>- Build out pluggable authorization for our configs.
>- This includes testing (and possibly doing something similar to Storm,
>where they have a some testing IAuthorizers, e.g. NoopAuthorizer,
>DenyAuthorizer, etc.)
>- Ensure that all the code paths consistently flow through this
>Authorization.
>- Build a Ranger compatible version of this.
>- Define the Ranger plugin for this.
>- Make sure auditing is defined.
>- Integration testing (particularly with Kerberos. After all, if they
>want to do authorization and auditing, they're almost certainly using
>Kerberos).
>
> Is there anything missing that we'd need or want for this?  Are there any
> other concerns we'd want to make sure are taken care of?
>


-- 
A.Nazemian

Re: Authorization for Configuration

[Ali Nazemian]

Hi Justin,

By configuration do you mean the sensor related configurations only? Are
you limiting the scope of this activity to the management-UI or also
Alert-UI as well? For example, defining different roles (pre-defined
or customizable) and the fine-grained integration with Ranger?

Cheers,
Ali

On Wed, Nov 14, 2018 at 1:25 AM Justin Leet  wrote:

> Hi all,
>
> Right now, our various configs can be modified by anyone with access to the
> various scripts. I'd like to start a discussion around building out some
> authorization to be able to add some more fine grained controls around
> this.
>
> Other projects have some variants on how to accomplish this.  Typically,
> this follows a pattern of calling out to a interface/class that takes in
> the operation and context (user and other info) and returns true/false if
> something is authorized.
>
> In my mind, what we would need out of this is
>
>- Ability to apply fine grained permissions
>- The various scripts and UI should flow this authorization framework.
>I believe most (if not all) of our configuration flows through
>ConfigurationsUtils.  Anything that doesn't should either be hooked in
> or
>refactored to flow through the same codepaths.
>- Pluggability. We shouldn't force only one authorizer.
>
> In particular, I'm proposing we use Apache Ranger
>  as a supported authorization framework,
> implementing it alongside the authorization framework to validate what we
> build. In my mind, the main catch with Ranger is that, based on my
> understanding, we won't be able to restrict users with direct access to
> ZooKeeper via it's CLI (e.g. Ranger can't mirror it's ACLs down into ZK's
> ACLs).  I believe this is a reasonable restriction, especially as the
> management UI gets improved to handle more of the configuration burden and
> the number of users with access to ZK CLI begins to decrease.  Users can
> still add ZK ACLs separately to enforce that access there.
>
> For anyone not familiar with Ranger, essentially you build a plugin that
> hooks into the existing component's authorization framework (e.g. for
> Storm, the plugin runs through the IAuthorizer
> <
> https://storm.apache.org/releases/1.2.2/javadocs/org/apache/storm/security/auth/IAuthorizer.html
> >
> interface, for Yarn it runs through YarnAuthorizationProvider
> <
> http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/apidocs/org/apache/hadoop/yarn/security/YarnAuthorizationProvider.html
> >).
> Additionally, Ranger provides auditing capabilities for this authorization
> and has plugins for a good portion of our stack already (so users can
> already setup ACLs on HDFS, Storm, etc.). Checkout the Ranger Github
>  for a list of the plugins they have
> built in.
>
> What this means for Metron is building out an authorization setup similar
> to Storm or Yarn or whatever we choose. We'll want this anyway, to allow
> our solution to be pluggable.  At that point, we build an implementation of
> the authorizer compatible with Ranger along with the plugin.
>
> I think this could probably be a fairly small feature branch, which I'm
> suggesting primarily to do the Ranger implementation alongside the general
> authorization work to validate what's being built.  I think the main
> tasking would be something similar to:
>
>- Build out pluggable authorization for our configs.
>- This includes testing (and possibly doing something similar to Storm,
>where they have a some testing IAuthorizers, e.g. NoopAuthorizer,
>DenyAuthorizer, etc.)
>- Ensure that all the code paths consistently flow through this
>Authorization.
>- Build a Ranger compatible version of this.
>- Define the Ranger plugin for this.
>- Make sure auditing is defined.
>- Integration testing (particularly with Kerberos. After all, if they
>want to do authorization and auditing, they're almost certainly using
>Kerberos).
>
> Is there anything missing that we'd need or want for this?  Are there any
> other concerns we'd want to make sure are taken care of?
>


-- 
A.Nazemian

Re: [DISCUSS] Knox SSO feature branch review and features

[Ryan Merriman]

I just put up a PR that adds Metron as a Knox service here:
https://github.com/apache/metron/pull/1275.  This should give everyone a
good idea of what is involved.  I added a section on outstanding items that
highlights some of the things we have been discussion here.

On Fri, Nov 16, 2018 at 10:54 AM Ryan Merriman  wrote:

> I would also add that defaulting to Knox being on simplifies things at a
> technical level.
>
> On Fri, Nov 16, 2018 at 10:52 AM Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
>> That's fantastic, thanks for that detail.
>>
>> Also, I'm in agreement with the recent comments from Otto and Simon.
>>
>> On Fri, Nov 16, 2018 at 9:49 AM Ryan Merriman 
>> wrote:
>>
>> > I was still able to spin up the UI locally and debug in my testing.  I
>> am
>> > in complete agreement, we need to ensure the developer experience
>> doesn't
>> > change.
>> >
>> > On Fri, Nov 16, 2018 at 10:47 AM Michael Miklavcic <
>> > michael.miklav...@gmail.com> wrote:
>> >
>> > > Ryan, what's remote debugging look like for UI testing with Knox
>> enabled?
>> > > Anything we lose from a dev testability standpoint? The discussion of
>> > > defaults sounds reasonable to me, and I'd like to understand any other
>> > > tradeoffs there may be for non-prod deployments like full dev.
>> > >
>> > > On Fri, Nov 16, 2018 at 7:20 AM Ryan Merriman 
>> > wrote:
>> > >
>> > > > Most of the research I've done around adding Metron as a Knox
>> service
>> > is
>> > > > based on how other projects do it.  The documentation is not easy to
>> > > follow
>> > > > so I learned by reading other service definition files.  The
>> assumption
>> > > > that we are doing things drastically different is false.
>> > > >
>> > > > I completely agree with Simon.  Why would we want to be dependent on
>> > > Knox's
>> > > > release cycle?  How does that benefit us?  It may reduce some
>> > operational
>> > > > complexity but it makes our install process more complicated
>> because we
>> > > > require a certain version of Knox (who knows when that gets
>> released).
>> > > > What do we do in the meantime?  I would also like to point out that
>> > > Metron
>> > > > is inherently different than other Hadoop stack services.  We are a
>> > > > full-blown application with multiple UIs so the way we expose
>> services
>> > > > through Knox may be a little different.
>> > > >
>> > > > I think this will be easier to discuss when we can all see what is
>> > > actually
>> > > > involved.  I am working on a PR that adds Metron as a Knox service
>> and
>> > > will
>> > > > have that out soon.  That should give everyone more context.
>> > > >
>> > > > On Fri, Nov 16, 2018 at 7:39 AM Simon Elliston Ball <
>> > > > si...@simonellistonball.com> wrote:
>> > > >
>> > > > > You could say the same thing about Ambari, but that provides
>> mpacks.
>> > > Knox
>> > > > > is also designed to be extensible through Knox service stacks
>> since
>> > > they
>> > > > > realized they can’t support every project. The challenge is that
>> the
>> > > docs
>> > > > > have not made it as easy as they could for the ecosystem to plug
>> into
>> > > > Knox,
>> > > > > which has led to some confusion around this being a recommended
>> > pattern
>> > > > > (which it is).
>> > > > >
>> > > > > The danger of trying to get your bits into Knox is that that ties
>> you
>> > > to
>> > > > > their release cycle (a problem Ambari has felt hard, hence their
>> > > > community
>> > > > > is moving away from the everything inside model towards
>> everything is
>> > > an
>> > > > > mpack).
>> > > > >
>> > > > > A number of implementations of Knox also use the approach Ryan is
>> > > > > suggesting for their own organization specific end points, so it’s
>> > not
>> > > > like
>> > > > > this is an uncommon, or anti-pattern, it’s more the way Knox is
>> > > designed
>> > > > to
>> > > > > work in the future, than the legacy of it only being able to
>> handle a
>> > > > > subset of Hadoop projects.
>> > > > >
>> > > > > Knox remains optional In our scenario, but we keep control over
>> the
>> > > > > shipping of things like rewrite rules, which allows Metron to
>> control
>> > > its
>> > > > > release destiny should things like url patterns in the ui need to
>> > > change
>> > > > > (with a new release of angular / new module / new rest endpoint
>> etc)
>> > > > > instead of making a Metron release dependent on a Knox release.
>> > > > >
>> > > > > Imagine how we would have done with the Ambari side if we’d had to
>> > wait
>> > > > > for them to release every time we needed to change something in
>> the
>> > > > > mpack... we don’t want that happening with Knox.
>> > > > >
>> > > > > Simon
>> > > > >
>> > > > > > On 16 Nov 2018, at 13:22, Otto Fowler 
>> > > wrote:
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://issues.apache.org/jira/browse/KNOX-841?jql=project%20%3D%20KNOX%20AND%20text%20~%20support
>> > > > > >
>> > > > > > Solr is angular for example.
>> > > > > >
>> > 

Re: [ANNOUNCE] Shane Ardell is a committer

[Mohan Venkateshaiah]

Congrats Shane !!

Thanks 
Mohan DV

On 11/19/18, 10:26 PM, "Michael Miklavcic"  wrote:

Congrats!

On Mon, Nov 19, 2018 at 8:56 AM Shane Ardell 
wrote:

> I want to extend a huge thank you to everyone part of Apache Metron's PMC
> for offering me this opportunity!
>
> Cheers,
> Shane
>
> On Mon, Nov 19, 2018 at 4:53 PM zeo...@gmail.com  wrote:
>
> > Congrats Shane!
> >
> > Jon
> >
> > On Mon, Nov 19, 2018 at 10:43 AM Anand Subramanian <
> > asubraman...@hortonworks.com> wrote:
> >
> > > Many congratulations, Shane!
> > >
> > > Cheers,
> > > Anand
> > >
> > > On 11/19/18, 8:36 PM, "James Sirota"  wrote:
> > >
> > >
> > > The Project Management Committee (PMC) for Apache Metron has
> invited
> > > Shane Ardell to become a committer and we are pleased to announce that
> he
> > > has accepted.  I wanted to congratulate Shane on this achievement.
> > >
> > >
> > > Being a committer enables easier contribution to the project since
> > > there is no need to go via the patch submission process. This should
> > enable
> > > better productivity. Being a PMC member enables assistance with the
> > > management and to guide the direction of the project.
> > > ---
> > > Thank you,
> > >
> > > James Sirota
> > > PMC- Apache Metron
> > > jsirota AT apache DOT org
> > >
> > >
> > >
> > > --
> >
> > Jon Zeolla
> >
>

Re: [ANNOUNCE] Shane Ardell is a committer

[Michael Miklavcic]

Congrats!

On Mon, Nov 19, 2018 at 8:56 AM Shane Ardell 
wrote:

> I want to extend a huge thank you to everyone part of Apache Metron's PMC
> for offering me this opportunity!
>
> Cheers,
> Shane
>
> On Mon, Nov 19, 2018 at 4:53 PM zeo...@gmail.com  wrote:
>
> > Congrats Shane!
> >
> > Jon
> >
> > On Mon, Nov 19, 2018 at 10:43 AM Anand Subramanian <
> > asubraman...@hortonworks.com> wrote:
> >
> > > Many congratulations, Shane!
> > >
> > > Cheers,
> > > Anand
> > >
> > > On 11/19/18, 8:36 PM, "James Sirota"  wrote:
> > >
> > >
> > > The Project Management Committee (PMC) for Apache Metron has
> invited
> > > Shane Ardell to become a committer and we are pleased to announce that
> he
> > > has accepted.  I wanted to congratulate Shane on this achievement.
> > >
> > >
> > > Being a committer enables easier contribution to the project since
> > > there is no need to go via the patch submission process. This should
> > enable
> > > better productivity. Being a PMC member enables assistance with the
> > > management and to guide the direction of the project.
> > > ---
> > > Thank you,
> > >
> > > James Sirota
> > > PMC- Apache Metron
> > > jsirota AT apache DOT org
> > >
> > >
> > >
> > > --
> >
> > Jon Zeolla
> >
>

Re: [ANNOUNCE] Shane Ardell is a committer

[Shane Ardell]

I want to extend a huge thank you to everyone part of Apache Metron's PMC
for offering me this opportunity!

Cheers,
Shane

On Mon, Nov 19, 2018 at 4:53 PM zeo...@gmail.com  wrote:

> Congrats Shane!
>
> Jon
>
> On Mon, Nov 19, 2018 at 10:43 AM Anand Subramanian <
> asubraman...@hortonworks.com> wrote:
>
> > Many congratulations, Shane!
> >
> > Cheers,
> > Anand
> >
> > On 11/19/18, 8:36 PM, "James Sirota"  wrote:
> >
> >
> > The Project Management Committee (PMC) for Apache Metron has invited
> > Shane Ardell to become a committer and we are pleased to announce that he
> > has accepted.  I wanted to congratulate Shane on this achievement.
> >
> >
> > Being a committer enables easier contribution to the project since
> > there is no need to go via the patch submission process. This should
> enable
> > better productivity. Being a PMC member enables assistance with the
> > management and to guide the direction of the project.
> > ---
> > Thank you,
> >
> > James Sirota
> > PMC- Apache Metron
> > jsirota AT apache DOT org
> >
> >
> >
> > --
>
> Jon Zeolla
>

Re: [ANNOUNCE] Shane Ardell is a committer

[zeo...@gmail.com]

Congrats Shane!

Jon

On Mon, Nov 19, 2018 at 10:43 AM Anand Subramanian <
asubraman...@hortonworks.com> wrote:

> Many congratulations, Shane!
>
> Cheers,
> Anand
>
> On 11/19/18, 8:36 PM, "James Sirota"  wrote:
>
>
> The Project Management Committee (PMC) for Apache Metron has invited
> Shane Ardell to become a committer and we are pleased to announce that he
> has accepted.  I wanted to congratulate Shane on this achievement.
>
>
> Being a committer enables easier contribution to the project since
> there is no need to go via the patch submission process. This should enable
> better productivity. Being a PMC member enables assistance with the
> management and to guide the direction of the project.
> ---
> Thank you,
>
> James Sirota
> PMC- Apache Metron
> jsirota AT apache DOT org
>
>
>
> --

Jon Zeolla

Re: [ANNOUNCE] Shane Ardell is a committer

[Anand Subramanian]

Many congratulations, Shane! 

Cheers,
Anand

On 11/19/18, 8:36 PM, "James Sirota"  wrote:


The Project Management Committee (PMC) for Apache Metron has invited Shane 
Ardell to become a committer and we are pleased to announce that he has 
accepted.  I wanted to congratulate Shane on this achievement. 


Being a committer enables easier contribution to the project since there is 
no need to go via the patch submission process. This should enable better 
productivity. Being a PMC member enables assistance with the management and to 
guide the direction of the project.
--- 
Thank you,

James Sirota
PMC- Apache Metron
jsirota AT apache DOT org

[ANNOUNCE] Shane Ardell is a committer

[James Sirota]

The Project Management Committee (PMC) for Apache Metron has invited Shane 
Ardell to become a committer and we are pleased to announce that he has 
accepted.  I wanted to congratulate Shane on this achievement. 


Being a committer enables easier contribution to the project since there is no 
need to go via the patch submission process. This should enable better 
productivity. Being a PMC member enables assistance with the management and to 
guide the direction of the project.
--- 
Thank you,

James Sirota
PMC- Apache Metron
jsirota AT apache DOT org