k, for
now we should perhaps clearly document that this would be a breaking change
after upgrade, so users should fix the plugins before they proceed.
On Wed, Jun 13, 2018 at 3:42 AM Arina Yelchiyeva
wrote:
> From the Drill code workspaces are already case insensitive (though the
> documen
>From the Drill code workspaces are already case insensitive (though the
documentation states the opposite). Since there were no complaints from the
users so far, I believe there are not many (if any) who uses the same names
in different case.
Regarding those users that already have duplicat
and DFS. Or configured workspaces
tmp and TMP. In this case, they'd need to rename those. One thing I'm not
clear on is how we'll handle upgrades in these cases.
On Tue, Jun 12, 2018 at 10:31 AM Paul Rogers
wrote:
> Hi All,
>
> As it turns out, this topic has been discuss
s /TMP and /tmp, he can create two
workspaces but not both with tmp name. For example, tmp vs tmp_u.
Table names case sensitivity are treated per plugin. For example, system
plugins (information_schema, sys) table names (views, tables) should be
case insensitive. Actually, currently for sys plugin t
> vs information_schema).
> Workspace (schemas) names to be case insensitive (ROOT vs root, TMP vs
> tmp). Even if user has two directories /TMP and /tmp, he can create two
> workspaces but not both with tmp name. For example, tmp vs tmp_u.
> Table names case sensitivity are treated per
insensitive (ROOT vs root, TMP vs
tmp). Even if user has two directories /TMP and /tmp, he can create two
workspaces but not both with tmp name. For example, tmp vs tmp_u.
Table names case sensitivity are treated per plugin. For example, system
plugins (information_schema, sys) table names (views, tables
On Tue, Jun 12, 2018 at 5:01 AM, Arina Yelchiyeva <
arina.yelchiy...@gmail.com> wrote:
> Hi all,
>
> Currently Drill we treat storage plugin names and workspaces as
> case-sensitive [1].
> Names for storage plugins and workspaces are defined by the user. So we
> allow to cr
Hi all,
Currently Drill we treat storage plugin names and workspaces as
case-sensitive [1].
Names for storage plugins and workspaces are defined by the user. So we
allow to create plugin -> DFS and dfs, workspace -> tmp and TMP.
I have a suggestion to move to case insensitive approach and
Normally workspaces in Drill DFS plugin should be tied to a directory in the
underlying DFS.
If the user/group that logged in does not have read/write/exec permissions on
the directory, it shouldn’t show up in the show schemas nor should the user be
able to select the workspace in Drill.
Did
Hi Francis,
I don’t believe that Drill currently has a way to do this: workspaces are
global resources shared across all users. The admin (only) can edit all plugin
and workspace definitions.
We’d need some form of security tags on each definition, and a way to map users
to tags to make this
Hi,
I have a situation where I would like to restrict access to workspaces
based on the user. I have an instance where I would like to allow some
third-party access to a subset of views. I can't find a standard method
here.
The only similar issue I could find was this:
https://issues.apach
016, at 5:05 AM, John Omernik wrote:
> >
> > Prior to opening a JIRA on this, I was curious what the community
> thought.
> > I'd like to have a setting for workspaces that would indicate "hidden".
> > (Defaulting to false if not specified to not bre
community thought.
> I'd like to have a setting for workspaces that would indicate "hidden".
> (Defaulting to false if not specified to not break any already implemented
> workspace definitions)
>
> For example:
>
> "workspaces" {
> "
+2
I really like this idea.
—C
> On May 25, 2016, at 08:52, Jim Scott wrote:
>
> +1
>
> On Wed, May 25, 2016 at 7:05 AM, John Omernik wrote:
>
>> Prior to opening a JIRA on this, I was curious what the community thought.
>> I'd like to have a setting
+1
On Wed, May 25, 2016 at 7:05 AM, John Omernik wrote:
> Prior to opening a JIRA on this, I was curious what the community thought.
> I'd like to have a setting for workspaces that would indicate "hidden".
> (Defaulting to false if not specified to not break
Prior to opening a JIRA on this, I was curious what the community thought.
I'd like to have a setting for workspaces that would indicate "hidden".
(Defaulting to false if not specified to not break any already implemented
workspace definitions)
For example:
"w
Guillermo Caudillo Gallegos <
>>> odin.guille...@gmail.com > wrote:
>>>>
>>>> The plugins are working fine in the embbed mode, but when i start the
>>>> drillbit on each server and connect via drill-conf i don't see them.
>>>>
, Odin Guillermo Caudillo Gallegos <
> > > odin.guille...@gmail.com > wrote:
> > > >
> > > > The plugins are working fine in the embbed mode, but when i start the
> > > > drillbit on each server and connect via drill-conf i don't see them.
>
Do i need to configure another parameter apart from the zookeeper
> servers
> > > in the drill-override.conf file?
> > >
> > > 2016-05-13 11:01 GMT-05:00 Andries Engelbrecht <
> > aengelbre...@maprtech.com >:
> > >
> > >> If D
nd connect via drill-conf i don't see them.
> > Do i need to configure another parameter apart from the zookeeper servers
> > in the drill-override.conf file?
> >
> > 2016-05-13 11:01 GMT-05:00 Andries Engelbrecht <
> aengelbre...@maprtech.com>:
> >
>
ries Engelbrecht >:
>
> > If Drill was correctly installed in distributed mode the storage plugin
> > and workspaces will be used by the Drill cluster.
> >
> > Make sure the plugin and workspace was correctly configured and accepted.
> >
> > Are you usin
de.conf file?
>
> 2016-05-13 11:01 GMT-05:00 Andries Engelbrecht :
>
>> If Drill was correctly installed in distributed mode the storage plugin
>> and workspaces will be used by the Drill cluster.
>>
>> Make sure the plugin and workspace was correctly configu
recht :
> If Drill was correctly installed in distributed mode the storage plugin
> and workspaces will be used by the Drill cluster.
>
> Make sure the plugin and workspace was correctly configured and accepted.
>
> Are you using the WebUI or REST to configure the storage plugins?
>
If Drill was correctly installed in distributed mode the storage plugin and
workspaces will be used by the Drill cluster.
Make sure the plugin and workspace was correctly configured and accepted.
Are you using the WebUI or REST to configure the storage plugins?
--Andries
> On May 13, 2016,
Is there a way to configure workspaces on a distributed installation?
Cause i only see the default plugin configuration but not the one that i
created.
Thanks
; > document that explain the API:
> > > >
> > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1mRsuWk4Dpt6ts-jQ6ke3bB30PIwanRiCPfGxRwZEQME/edit
> > > >
> > > >
> > > > On Fri, Oct 9, 2015 at 10:36 AM
k to a Google
> > > document that explain the API:
> > >
> > >
> > >
> >
> https://docs.google.com/document/d/1mRsuWk4Dpt6ts-jQ6ke3bB30PIwanRiCPfGxRwZEQME/edit
> > >
> > >
> > > On Fri, Oct 9, 2015 at 10:36 AM, John Omernik
> wrote:
> > >
ST API to do so. Here is a link to a Google
> > document that explain the API:
> >
> >
> >
> https://docs.google.com/document/d/1mRsuWk4Dpt6ts-jQ6ke3bB30PIwanRiCPfGxRwZEQME/edit
> >
> >
> > On Fri, Oct 9, 2015 at 10:36 AM, John Omernik wrote:
> >
>
o so. Here is a link to a Google
> document that explain the API:
>
>
> https://docs.google.com/document/d/1mRsuWk4Dpt6ts-jQ6ke3bB30PIwanRiCPfGxRwZEQME/edit
>
>
> On Fri, Oct 9, 2015 at 10:36 AM, John Omernik wrote:
>
> > Is there an easy way for a user with the proper
per privs to add workspaces in
> Drill? I'd love to have a scenario where I add users to my cluster, and I
> create a home directory via MapR Volumes, set quotas, etc, and then auto
> create a workspace for the user to connect and play with data.
>
> I looked at the docs and didn
Is there an easy way for a user with the proper privs to add workspaces in
Drill? I'd love to have a scenario where I add users to my cluster, and I
create a home directory via MapR Volumes, set quotas, etc, and then auto
create a workspace for the user to connect and play with data.
I look
31 matches
Mail list logo
