sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shreepadma Venugopalan (JIRA)" <>
Subject [jira] [Commented] (SENTRY-27) Refactor to be able to support different provider backends (e.g. db vs file)
Date Tue, 08 Oct 2013 21:00:46 GMT


Shreepadma Venugopalan commented on SENTRY-27:

This proposal sounds good to me. [~brocknoland]: What's the context we are talking about?

> Refactor to be able to support different provider backends (e.g. db vs file)
> ----------------------------------------------------------------------------
>                 Key: SENTRY-27
>                 URL:
>             Project: Sentry
>          Issue Type: Sub-task
>    Affects Versions: 1.2.0
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>             Fix For: 1.3.0
> see this review request:
> Here's the part that is relevant to this JIRA (note: this is just refactoring to be able
to support other backends, this is not support for other backends).
> The issue right now is the sentry-provider-file and sentry-provider-hive have things
that are both backend-specific (e.g. PolicyFileConstants) and backend-agnostic (e.g. HadoopMappingService).
 Let's take an specific use case: we want to use the HadoopGroupResourceAuthorizationProvider
via a database-backend.  If today I specify the AuthorizationProvider to be say "org.apache.sentry.provider.hive.HadoopGroupResourceAuthorizationProvider"
it will automatically be file-backed because it automatically instantiates a SimpleHivePolicyEngine
which in turn uses the file.SimplePolicyParser.  So, we should separate out the specification
of the AuthorizationProvider and the PolicyEngine.  So I would specify the AuthorizationProvider
to be "org.apache.sentry.provider.hive.HadoopGroupResourceAuthorizationProvider" and the PolicyEngine
to be "org.apache.sentry.policyengine.db.DBPolicyEngine" (that example sort of sucks because
it has db twice -- maybe dbbackend.DBPolicyEngine).  I think that is pretty similar to what
you are saying -- just using "PolicyEngine" or "Policy" instead of "Permission Implementation".
> In my mind, there are 6 different files-types here, if we assume support for file/db
backends and db/solr services:
> Policy-Engine Specific {common, db, solr}
> Non-Policy-Engine Specific {common, file, db}
> Now I don't have a huge preference for where this should all go, except that the policy-engine
specific stuff for db and solr should be in their own package, to avoid pulling in a bunch
of dependencies if they aren't needed.  So this could be something like:
> sentry-policy/sentry-policy-db
> sentry-policy/sentry-policy-solr
> sentry-policy/sentry-policy-common
> sentry-provider/sentry-provider-backend-file
> sentry-provider/sentry-provider-backend-db
> sentry-provider/sentry-provider-common
> Or we could just throw all the "common" stuff into core.

This message was sent by Atlassian JIRA

View raw message