in ruby script which you can apply in your
cluster.
That way you would be able to verify yourself :-)
On Wed, Feb 26, 2014 at 3:51 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
Thanks. I am unfortunately on 0.96 still, but looking forward to having
it
working in 0.98 when we upgrade
text would be even better.
On Tue, Feb 25, 2014 at 12:30 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
I don't really understand how HBase permission is expected to work then.
A
user needs the Create permission in order to be able to create their own
tables. But that permission also
another suggested approach?
On Wed, Feb 26, 2014 at 12:00 PM, Ted Yu yuzhih...@gmail.com wrote:
I was looking at HBASE-9206 : the last comment was 5 months ago.
On Wed, Feb 26, 2014 at 8:57 AM, Alex Nastetsky anastet...@spryinc.com
wrote:
Thanks for all that detail. Re: updating
, Feb 26, 2014 at 9:36 AM, Alex Nastetsky anastet...@spryinc.com
wrote:
Does that indicate to you an abandoned ticket?
I think that HBASE-8409 alone would satisfy my needs because it prevents
other tenants from dropping and altering my tables (the W permission). I
can live with users
is covered.
On Wed, Feb 26, 2014 at 2:08 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
I haven't looked at the patch, just the ticket description. Here is an
excerpt:
Lets see an example on how privileges work with namespaces.
User Mike request for a namespace named hbase_perf
Thanks, I am watching that issue now.
On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu yuzhih...@gmail.com wrote:
I tried that and stumbled into HBASE-10621
On Wed, Feb 26, 2014 at 2:48 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
Thanks Ted.
Can you use user X to grant hrt_1 permission
at 6:41 PM, Ted Yu yuzhih...@gmail.com wrote:
I put up a patch which I have tested locally.
On Wed, Feb 26, 2014 at 2:56 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
Thanks, I am watching that issue now.
On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu yuzhih...@gmail.com wrote:
I tried
According to
http://hbase.apache.org/book/hbase.accesscontrol.configuration.html#d2566e5780,
the Enable/Disable operation is controlled by the Admin permission.
However, it seems to be controlled instead by the Create permission. Is
this a bug or a typo in the documentation?
hbase(main):002:0
, 2014 at 12:12 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
According to
http://hbase.apache.org/book/hbase.accesscontrol.configuration.html#d2566e5780
,
the Enable/Disable operation is controlled by the Admin permission.
However, it seems to be controlled instead by the Create
a table is disabled, the ability to disable a table is also given by
the Create permission. What am I missing?
On Tue, Feb 25, 2014 at 3:25 PM, Alex Nastetsky anastet...@spryinc.comwrote:
Sounds like either permission is sufficient. Either way, the documentation
could be improved.
Thanks
My understanding of the hbase.superuser ACL is that members of a user group
specified here (prefixed with @) will have full rights on HBase. However,
it seems that the ADMIN right is missing.
Below, I have an example of using HBase as user anastetsky who belongs to
a group specified in
Additionally, it seems like the hbase.superuser ACL can only take a single
username, even if you don't include any groups. All usernames beyond the
first will be ignored.
On Mon, Feb 24, 2014 at 4:12 PM, Alex Nastetsky anastet...@spryinc.comwrote:
My understanding of the hbase.superuser ACL
That fixed it, thanks!
On Mon, Jan 27, 2014 at 4:21 PM, Ted Yu yuzhih...@gmail.com wrote:
Thanks for reporting this, Alex.
I logged HBASE-10426 and put up a patch.
Mind giving it a try ?
On Mon, Jan 27, 2014 at 12:46 PM, Alex Nastetsky anastet...@spryinc.com
wrote:
Hi,
When I
13 matches
Mail list logo
