[GitHub] metron pull request #891: METRON-1282 creating a new topic using the rest en...

[MohanDV]

GitHub user MohanDV reopened a pull request:

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

METRON-1282 creating a new topic using the rest end point breaks the list 
topic API


## Contributor Comments
Creating a kafka topic using the rest endpoint doesn't add the required ACL 
to topic for the current user automatically. This will cause the all other 
kafka operation rest endpoints fail including listing the topics.  

**Steps to Verify manually**
1. Spin up Full Dev
2. Go to Swagger at http://node1:8082/swagger-ui.html#/kafka-controller
3. Create a kafka topic using (/api/v1/kafka/topic)
4. List all the kafka topics using (/api/v1/kafka/topic) 
5. You should see the list of all kafka topics including newly created 
topic without any authorization error.

## 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?
- [ ] 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 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] 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:
- [ ] 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/MohanDV/metron METRON-1282

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

https://github.com/apache/metron/pull/891.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 #891


commit fedc916d7e3f61ccbb6fe670fdc5e9dc808f5995
Author: Mohan Venkateshaiah 
Date:   2018-01-08T14:56:51Z

Added code to permission the required ACL to the current user automatically 
while creating a new topic using the rest end point.




---

[GitHub] metron issue #934: METRON-1423: Ambari work to handle Solr configuration

[merrimanr]

Github user merrimanr commented on the issue:

https://github.com/apache/metron/pull/934
  
I agree with @justinleet.  I would prefer we use Solr 6+.  At some point 
HDP Search will move to 6+ and we can easily switch to the Mpack since 
installing Solr is a manual step now.  Happy to document that once we are all 
in agreement.

As for the parameters we expose in Ambari, I'm referring to the parameters 
stored in Zookeeper that the SolrWriter reads.  They are:

- solr.zookeeper
- solr.commitPerBatch
- solr.commit.waitSearcher
- solr.commit.waitFlush
- solr.commit.soft
- solr.collection
- solr.http.config

Currently Ambari only exposes the "solr.zookeeper" parameter which is 
necessary to get the indexing topology writing to Solr.  I think a reasonable 
solution would be to include all the others except "solr.http.config" since 
it's an advanced config.  Storm tuning parameters are independent of the writer 
implementation and already exposed in Ambari.  

For the collection service actions, it would mirror what we expose for ES:  
creating and deleting templates (schemas in Solr terms).


---

[GitHub] metron issue #895: METRON-1394:Create Rest endpoint to add the ACL for curre...

[simonellistonball]

Github user simonellistonball commented on the issue:

https://github.com/apache/metron/pull/895
  
One option here, that would make me less grumpy would be to incorporate the 
acl actions with the topic creation actions, which at least prevents nefarious 
insiders from using this endpoint to give themselves access to arbitrary topics 
they didn't create.


---

[GitHub] metron issue #934: METRON-1423: Ambari work to handle Solr configuration

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/metron/pull/934
  
I would just like it documented as to why we are not using the HDP solr 
mpack.
Although, I would think we would be using that mpack as the example for 
ours?


---

Re: [DISCUSS] Persistence store for user profile settings

[Michael Miklavcic]

I'm also good with HBase.

On Fri, Feb 9, 2018 at 2:14 PM, Nick Allen  wrote:

> +1 I think going with HBase is a good approach for now.  Thanks for laying
> out the pros and cons.
>
> On Fri, Feb 9, 2018 at 3:46 PM, Ryan Merriman  wrote:
>
> > I would like to bring this discussion to a conclusion and update the PR
> > accordingly.  To clarify on whether we depend on an RDBMS right now, we
> do
> > but only for authentication which will probably be replaced at some
> point.
> > So the answer is not really.  I personally agree with Simon and think we
> > should use HBase because this use case fits the data model and it's
> already
> > in our stack.  I would add that with HBase we can move the schema
> evolution
> > complexity to the application layer and hide it from the user.  This will
> > make upgrades easier which is my main point of contention.  I also agree
> > with Nick in that I do think there may be a place for a RDBMS in the
> future
> > but we can always add it back.
> >
> > The 2 choices seems to be either an RDBMS or HBase.  Here is a summary
> > based on comments in this discussion:
> >
> > RDBMS
> > - some are not too worried about schema evolution as the data model will
> > likely be simple
> > - avoiding having to alter tables when upgrading would be ideal
> > - works with ORM tools
> > - is flexible and could be useful for future use cases
> >
> > HBase
> > - might involve boilerplate code if not covered elsewhere in Metron
> > - key/value is good enough for user profile settings
> > - data replication for free
> >
> > Reading over this thread again I get the impression there is a slight
> > preference for HBase.  Want to give people one more change to chime in or
> > argue the other solution.  Let me know if I missed anything or didn't
> > include someone's argument.
> >
> >
> >
> > On Fri, Feb 2, 2018 at 8:24 AM, Nick Allen  wrote:
> >
> > > > Glad you agree with me that this isn’t HBase scale… it’s clearly
> not. I
> > > would never suggest introducing HBase for something like this, but
> since
> > > it’s there.
> > >
> > > Ah, gotcha.  Misunderstood your statement.
> > >
> > >
> > >
> > > On Fri, Feb 2, 2018 at 9:01 AM Simon Elliston Ball <
> > > si...@simonellistonball.com> wrote:
> > >
> > > > Glad you agree with me that this isn’t HBase scale… it’s clearly
> not. I
> > > > would never suggest introducing HBase for something like this, but
> > since
> > > > it’s there.
> > > >
> > > > On the idea of using the Ambari RDBMS for the same basis of it being
> > > > there, I see your point. That said, it can be postgres, sql server,
> > > mysql,
> > > > maria, oracle… various. Yes we have an ORM, but those are not nearly
> as
> > > > magic as they claim, and upgrade / schema evolution of an RDBMS often
> > > > involves some sort of platform dependent SQL migration in my
> > experience.
> > > I
> > > > would suggest that supporting that range of options is not a good
> idea
> > > for
> > > > us. The Ambari project also pretty much reserve the right to blow
> away
> > > that
> > > > infrastructure in upgrades (which is fair enough). So relying on
> there
> > > > being an RDBMS owned by another component is not something I would
> > > > necessarily say was a clean choice.
> > > >
> > > > Simon
> > > >
> > > > > On 2 Feb 2018, at 13:50, Nick Allen  wrote:
> > > > >
> > > > > I fall marginally on the side of an RDBMS.  There is definitely a
> > case
> > > to
> > > > > be made on both sides, but I'll point out a few things for the
> RDBMS.
> > > > >
> > > > >
> > > > > (1) Flexibility.  Using an RDBMS is going to provide us with much
> > > greater
> > > > > flexibility going forward.  We really don't know what the specific
> > use
> > > > > cases will be, but I am willing to bet they are user-focused
> > > > (preferences,
> > > > > etc).  The type of use cases that most web applications use an
> RDBMS
> > > for.
> > > > >
> > > > >
> > > > >> If anything I would like to see the current RDBMS dependency come
> > > out...
> > > > >
> > > > > (2) Don't we already have an RDBMS requirement for Ambari?  That's
> a
> > > > > dependency that we do not control.
> > > > >
> > > > >
> > > > >> ... hbase seems a good option (because we already have it there,
> it
> > > > would
> > > > > be kinda crazy at this scale if we didn’t already have it)
> > > > >
> > > > > (3) In this scenario, the RDBMS would not scale proportionally with
> > the
> > > > > amount of telemetry, it would scale based on usage; primarily the
> > > number
> > > > of
> > > > > users.  This is not "big data" scale.  I don't think we can make
> the
> > > case
> > > > > for HBase based on scale here.
> > > > >
> > > > >
> > > > >> We would also end up with, as Mike points out, a whole new disk
> > > > > deployment patterns and a bunch of additional DBA ops process
> > > > requirements
> > > > > for every install.
> > > > >
> > > > > (4) Most users that need 

[GitHub] metron issue #934: METRON-1423: Ambari work to handle Solr configuration

[simonellistonball]

Github user simonellistonball commented on the issue:

https://github.com/apache/metron/pull/934
  
Given that we're happy to accept limiting ourselves to a Hadoop 
distribution, it doesn't seem unfair to limit ourselves to a Solr distribution. 
While sticking pure raw Apache has some appeal, it may well make sense to stick 
to Ambari mpack based installs in the distro @ottobackwards suggest. 


---

[GitHub] metron pull request #935: METRON-1386: Fix Metron Website Required Links

[anandsubbu]

GitHub user anandsubbu opened a pull request:

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

METRON-1386: Fix Metron Website Required Links

## Contributor Comments
Made the following changes to the Metron ASF site:
* Fixed the missing entities and made corrections per the Apache TLP 
Website checks for [Metron](https://whimsy.apache.org/site/project/metron)
* Added Raghu and Anand as committers in the Community page

Please Note: This PR does not address the [graphics 
changes](https://issues.apache.org/jira/browse/METRON-1386?focusedCommentId=16309716=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16309716)
 required to conform to Apache standards, which is tracked by METRON-1456.

**Testing Steps**
Follow the below steps to test the changes 

1. From `metron/site` execute
```
bundle install
bundle exec jekyll serve
```
2. Navigate to http://localhost:4000 to review the site

Note that these steps are an excerpt from 
https://cwiki.apache.org/confluence/display/METRON/Website+PR+Merge.

## 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:
- [ ] Have you included steps to reproduce the behavior or problem that is 
being changed or addressed?
- [ ] Have you included steps or a guide to how the change may be verified 
and tested manually?
- [ ] 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 && 
dev-utilities/build-utils/verify_licenses.sh 
  ```

- [ ] Have you written or updated unit tests and or integration tests to 
verify your changes?
- [ ] 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)?
- [ ] 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:
- [ ] 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/anandsubbu/incubator-metron METRON-1386

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

https://github.com/apache/metron/pull/935.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 #935


commit 5622ac07b48b9f9ea862bb45ae396964343ccc59
Author: Anand Subramanian 
Date:   2018-02-12T09:25:47Z

First pass at fixing Apache TLP website checks




---