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
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.
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
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
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
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
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,
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
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
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
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
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
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.
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
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
15 matches
Mail list logo
