Re: [DISCUSS] Deprecating MySQL

2018-11-19 Thread 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

Re: [DISCUSS] Deprecating MySQL

2018-11-16 Thread Otto Fowler
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.

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread Michael Miklavcic
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

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread James Sirota
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

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread Michael Miklavcic
Just to clarify this point, I am not proposing we alter any interactions with Ambari and backing stores. I want to make sure we cover all the problems and provide good solutions where we're able. Again, just to reiterate my earlier point, I agree with the move to deprecate SQL/JPA for the UI. And

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread 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

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread Scott C. Cote
I’m certain that I can make the “adapter” for elastic too. and the adapter compatible with HBase for those that want hbase (for other reasons). Sorry that I was not clear about that. SCott Scott C. Cote scottcc...@gmail.com 972.900.1561 twitter: @scottccote > On Nov 13, 2018, at 5:51 PM,

Re: [DISCUSS] Deprecating MySQL

2018-11-15 Thread James Sirota
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

Re: [DISCUSS] Deprecating MySQL

2018-11-14 Thread Scott Cote
Allow someone to remove the dependence on hbase and only use Solr. For the way you use hbase for profiles, I can make Solr fulfill the same role. Sent from my iPhone > On Nov 13, 2018, at 5:41 PM, James Sirota wrote: > > Metron already works with Solr. It's not default yet, but all the

Re: [DISCUSS] Deprecating MySQL

2018-11-14 Thread Vets, Laurens
Which option would there be for people running installs not tied to an already existing LDAP or other authentication layer? Would that be where the local LDAP comes into play? On 13-Nov-18 04:42, Simon Elliston Ball wrote: > I've been coming across a number of organisations who are blocked from

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread Michael Miklavcic
Hey Scott, Solr is an install option, not a hard requirement. Users can also choose Elasticsearch currently. HBase is the only option we currently provide for streaming enrichments, ie we can depend on it being there for every install. On Tue, Nov 13, 2018, 4:31 PM Scott C. Cote Simon, > > Since

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread Michael Miklavcic
Haha, yeah I had to dredge that up from February as well to remember what ultimately ended up going into HBase. Before you get your hackles up, I think you misunderstood me - I believe we're on the same page. I am saying that the SQL store would have made sense just fine in that case. Not that we

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread James Sirota
Metron already works with Solr. It's not default yet, but all the internals are in. The profiler currently works with Hbase and I don't think we were ever planning on switching it to Solr. Just to clarify - metron can index telemetry into Solr. However, profiling of that telemetry is

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread Scott C. Cote
Simon, Since ya’ll are going to have SOLR in your installation (is this still true?), I could make the profile system rely upon SOLR instead of HBASE. At Lucidworks, I did this very thing with proprietary code, but I can make an adapter so the binaries can be stored in SOLR of arbitrary size.

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread 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

Re: [DISCUSS] Deprecating MySQL

2018-11-13 Thread Michael Miklavcic
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