sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SENTRY-4) Rename Configuration properties that mention hive but are sentry related
Date Mon, 16 Sep 2013 20:42:53 GMT

    [ https://issues.apache.org/jira/browse/SENTRY-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768731#comment-13768731
] 

Gregory Chanan commented on SENTRY-4:
-------------------------------------

With this rename, we should also decide what to do with the deprecated configs.

1) HiveAuthzConf currently has some access-based deprecated names, e.g.:
hive.access.provider.resource
hive.access.udf.whitelist
hive.access.allow.hive.impersonation

there is some attempt to make it backwards compatible, but it doesn't work AFAICT.  For example,
HiveAuthZBinding will make a call like:
{code}
    String resourceName =
        authzConf.get(AuthzConfVars.AUTHZ_PROVIDER_RESOURCE.getVar()) // AuthzConfVars.AUTHZ_PROVIDER_RESOURCE
is equivalent to hive.sentry.provider.resource
{code}
for backwards compatibility to work, a call to authZConf.get(hive.sentry.provider.resource)
would have to return the value of hive.access.provider.resource if hive.sentry.provider.resource
is not specified, but this doesn't happen (I can provide a quick test to demonstrate).

So, any users of hive.access.* already have to update their site files, so I'd argue for just
removing any deprecation support for hive.access.

2) After this is implemented, we have some new "deprecated" names, basically everything on
the left-hand side of my previous comment:
hive.sentry.provider
hive.sentry.server
etc.

For these, we should make them deprecated and have them work as expected, e.g. a call to 
{code}
String resourceName =
        authzConf.get(sentry.hive.provider.resource)
{code}
should work if only hive.sentry.provider.resource is given.

3) There is some question about what to log, e.g. when to give warnings for the usage of old
configs.  I think what makes the most sense is to warn if an old config ends up actually getting
used.  An alternative is to always warn if a deprecated config is specified, but this is a
pain to do correctly, e.g. you'd have to override all the "set" commands in hadoop's Configuration.

SUMMARY:

1) remove non-working deprecation code around hive.access.* properties
2) add working deprecation code around hive.sentry.* properties
3) warn about deprecated configs only if they actually end up being used

Thoughts?
                
> Rename Configuration properties that mention hive but are sentry related
> ------------------------------------------------------------------------
>
>                 Key: SENTRY-4
>                 URL: https://issues.apache.org/jira/browse/SENTRY-4
>             Project: Sentry
>          Issue Type: Improvement
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>
> I'm thinking of the following properties, I'll check if there are others:
> hive.sentry.provider -> sentry.provider
> hive.sentry.provider.resource -> sentry.provider.resource
> hive.sentry.server -> sentry.server
> I'm happy to implement this, just need some guidance on what you want to do about compatibility.
> I was thinking the following:
> 1) If only old names used: accept old values, log warning
> 2) If old and new names used: use new values, log warning about old names being ignored
> 3) If only old new names used: use new values, no log warning
> Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message