[
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
