[
https://issues.apache.org/jira/browse/HBASE-12745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290884#comment-14290884
]
Sean Busbey commented on HBASE-12745:
-------------------------------------
{quote}
bq.rolling upgrade from 0.98.6+ -> 1.0.
We will support rolling upgrade from one major version to next? I think as per
our compatibility agreement across major versions we won't.
{quote}
According to the [upgrade section of the ref
guide|http://hbase.apache.org/book.html#upgrade1.0.rolling.upgrade] and
HBASE-11164, we expressly support rolling upgrade from 0.98.y to 1.0.z.
{quote}
bq. Since they're IA.Public, shouldn't they be deprecated for a full major
version before removal?
We've been taking this shortcut with experimental APIs in 0.98 - anything
requiring HFile v3 is experimental until 1.0: tags, cell ACLs, the VC,
encryption - where we will immediately mark deprecated in 0.98 and remove in
1.0. Agreed this should be documented, mentioned in release notes, etc. If we
want to discontinue this practice or do something different in this case, I
have no strong opinion either way.
{quote}
I don't personally know anyone who'll be impacted by this, but I would have
been more comfortable with this treatment if the experimental classes were
marked IS.Unstable instead of IS.Evolving.
If the hfilev3 stuff is all experimental, I'm fine with continuing to treat it
that way. Since it's been a long time since hfilev3 was a topic of discussion,
I think we should probably bring the topic up on dev@ and user@ prior to the
1.0 release to make sure no one else is caught by surprise like I was.
Presuming we stick with the practice, I don't think a release note will be
sufficient. The [ref guide section on upgrading from 0.98 to
1.0|http://hbase.apache.org/book.html#upgrade1.0] needs to have the significant
changes section updated to call out that the HFilev3 features from 0.98 are
impacted, preferably with some kind of call out on what downstream folks need
to test. The note in 0.98 rolling upgrades that says there are no known issues
should probably also caveat for users of these features. Both of those things
seem bigger than this particular change, so it should be a follow on issue.
> Visibility Labels: support visibility labels for user groups.
> --------------------------------------------------------------
>
> Key: HBASE-12745
> URL: https://issues.apache.org/jira/browse/HBASE-12745
> Project: HBase
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.0.0, 0.98.9, 0.99.2
> Reporter: Jerry He
> Assignee: Jerry He
> Fix For: 1.0.0, 2.0.0, 0.98.10, 1.1.0
>
> Attachments: HBASE-12745-master-v1.patch,
> HBASE-12745-master-v2.patch, HBASE-12745-master-v3.patch,
> HBASE-12745-master-v4.patch, HBASE-12745-master-v5.patch,
> HBASE-12745-master-v6.patch, HBASE-12745-master-v7.patch,
> HBASE-12745-v7-0.98-with-update.patch, HBASE-12745-v7-0.98.patch,
> HBASE-12745-v7-branch1.patch
>
>
> The thinking is that we should support visibility labels to be associated
> with user groups.
> We will then be able grant visibility labels to a group in addition to
> individual users, which provides convenience and usability.
> We will use '@group' to denote a group name, as similarly done in
> AcccessController.
> For example,
> {code}
> set_auths '@group1', ['SECRET','PRIVATE']
> {code}
> {code}
> get_auth '@group1'
> {code}
> A user belonging to 'group1' will have all the visibility labels granted to
> 'group1'
> We'll also support super user groups as specified in hbase-site.xml.
> The code update will mainly be on the server side VisibilityLabelService
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
