You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Timothy Farkas (JIRA)" <ji...@apache.org> on 2017/08/17 00:11:00 UTC

[jira] [Comment Edited] (DRILL-5723) Support System/Session Internal Options

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

Timothy Farkas edited comment on DRILL-5723 at 8/17/17 12:10 AM:
-----------------------------------------------------------------

This is what I am thinking based on everyone's feedback:

* *Boot Internal Options:* Internal options which should not be modifiable at runtime:
** These can already be configured by adding them to drill-override.conf as Parth and Paul said. Options configured in this way would not be viewable from the sys options table because they are not contained in the sys options table.
* *System/Session Internal Options:* Internal options which can be modifiable at runtime:
** Currently not implemented and would be the primary focus of this feature. These would be viewable and settable from the command line.

*System/Session internal options* would be stored in the SystemOptionManager with the rest of the options. *System/Session internal options* would be distinguished from *boot internal options* by a whitelist in *drill-override.conf* where all internal options are prefixed in *drill.internal.options*. *System/Session internal options* would be distinguished from normal options by adding an internal flag to the OptionValue class.

If the user tries to:

* *See the normal system options:* select * from sys.options
** The options are filtered by the internal flag = false and only non internal options are returned.
* *See the internal system options:* select * from internal.options
** internal.options is an alias for sys.options so this query also looks at the data in the SystemOptionManager. But the use of this alias causes options to be filtered by their meta data to only return internal options.
* *alter session set `<system/session internal option>` = 'value':*
** This should succeed.

Supporting permissions for security parameters Parth mentioned could be implemented by adding the appropriate roles fields to OptionValues and modifying the option iterator appropriately.


was (Author: timothyfarkas):
This is what I am thinking based on everyone's feedback:

* *Boot Internal Options:* Internal options which should not be modifiable at runtime:
** These can already be configured by adding them to drill-override.conf as Parth and Paul said. Options configured in this way would not be viewable from the sys options table because they are not contained in the sys options table.
* *System/Session Internal Options:* Internal options which can be modifiable at runtime:
** Currently not implemented and would be the primary focus of this feature. These would be viewable and settable from the command line.

*System/Session internal options* would be stored in the SystemOptionManager with the rest of the options. *System/Session internal options* would be distinguished from *boot internal options* by a whitelist in *drill-override.conf* where all internal options are prefixed in *drill.internal.options*. *System/Session internal options* would be distinguished from normal options by adding the concept of metadata to the SystemOptionManager.

If the user tries to:

* *See the normal system options:* select * from sys.options
** The options are filtered by their metadata and only non internal options are returned.
* *See the internal system options:* select * from internal.options
** internal.options is an alias for sys.options so this query also looks at the data in the SystemOptionManager. But the use of this alias causes options to be filtered by their meta data to only return internal options.
* *alter session set `<system/session internal option>` = 'value':*
** This should succeed.

Also this feature may be a good stepping stone to support permissions for security parameters Parth mentioned. If we add the concept of meta data to the system table as Paul has suggested, then maybe it could easily be extended to hold permission / role information as well in the future.

> Support System/Session Internal Options
> ---------------------------------------
>
>                 Key: DRILL-5723
>                 URL: https://issues.apache.org/jira/browse/DRILL-5723
>             Project: Apache Drill
>          Issue Type: New Feature
>            Reporter: Timothy Farkas
>            Assignee: Timothy Farkas
>
> This is a feature proposed by [~ben-zvi].
> Currently all the options are accessible by the user in sys.options. We would like to add internal options which can be altered, but are not visible in the sys.options table. These internal options could be seen by another alias select * from internal.options. The intention would be to put new options we weren't comfortable with exposing to the end user in this table.
> After the options and their corresponding features are considered stable they could be changed to appear in the sys.option table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)