Tags are / were intended as special extra bits of metadata which may be associated with a cell, therefore stored adjacent to the cell's serialized representation, for use within the server process by coprocessors. They are not meant to be user visible. The default RPC codec strips them out. The replication RPC codec makes an exception so all cell state including tags are replicated. The initial users for tags were the AccessController and VisibiltyController coprocessors.
On Fri, Sep 22, 2017 at 10:46 AM, Josh Elser <els...@apache.org> wrote: > Maybe my expectations are just invalid to start :) > > I'm thinking about the cell-level visibility feature specifically. I'm > happy to back away from this point as I'm getting the impression that I'm > trying to call an apple an orange. > > Let me take an action to read what currently does exist and come back > later. I also need to look more closely at how YARN is using the Tags now > to understand if they way they're using the feature is inappropriate out of > the gates. > > > On 9/22/17 12:11 PM, Andrew Purtell wrote: > >> Tags are server side internal metadata. Some carry sensitive information >> like labels. I guess this could appear odd if not around for discussion >> when they were introduced. So what documentation can be improved to lessen >> the surprise? Javadoc? Online book? A JIRA with suggestions welcome. >> >> >> On Sep 22, 2017, at 9:07 AM, Josh Elser <els...@apache.org> wrote: >>> >>> I can appreciate how we've gotten to this point, it just struck me >>> extremely odd that the contents of a Tag weren't expected to be accessed by >>> users. "Arbitrary metadata that rides along with a cell, you just can't see >>> that metadata" ;) >>> >>> I totally understand not wanting to let another thing come into 2.0. >>> Like MikeD said, let's hope for a faster 3.0 and we can slate this for that >>> time. >>> >>> Thanks for entertaining the discussion. We'll just deal with the >>> "downstream pain" for 2.0. >>> >>> On 9/22/17 1:32 AM, ramkrishna vasudevan wrote: >>>> CellUtil similar type of methods. Coming to Tags yes there are not much >>>> cases where clients can directly set Tags. And I think we don't expose >>>> any >>>> APIs which allow you to use mutations with Tags. So probably moving to >>>> LimitedPrivate is better and mark with Evolving if there are some users >>>> depending on the internals of Tags and its impl. But this will be a One >>>> of >>>> case. >>>> And also since Tags are internal ideally the CellUtil#getTAgs() should >>>> have >>>> been in another Util method that is exposed with LimitedPrivate and also >>>> Tags if tags should be made LimitedPRivate. So this may help in not >>>> having >>>> a PRivate interface like Tag in a public CellUtil class. >>>> 3.0 is fine but need some clean up in 2.0? Indicating what could happen >>>> going forward from 2.0? >>>> Regards >>>> Ram >>>> >>>>> On Fri, Sep 22, 2017 at 2:59 AM, Sean Busbey <bus...@apache.org> >>>>> wrote: >>>>> Yeah. I mean, I think we should improve the situation. Just think >>>>> it's too much to bite off at this stage of 2.0, we can aim for 3.0 and >>>>> start working in some tooling to help us. >>>>> >>>>> On Thu, Sep 21, 2017 at 3:35 PM, Josh Elser <els...@apache.org> wrote: >>>>>> That really makes me groan (we have downstream users depending on code >>>>>> >>>>> we've >>>>> >>>>>> explicitly said "don't use"), but if that's what it is given the >>>>>> current >>>>>> state, so be it. My complaining won't fix it. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> On 9/21/17 4:25 PM, Sean Busbey wrote: >>>>>>> >>>>>>> We have lots of examples of including non-Public stuff in Public >>>>>>> APIs. >>>>>>> we have docs that advise folks to be wary on relying on them beyond >>>>>>> opaque symbols. >>>>>>> >>>>>>> ref: http://hbase.apache.org/book.html#hbase.client.api.surface >>>>>>> >>>>>>> On Thu, Sep 21, 2017 at 3:21 PM, Josh Elser <els...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I was going to suggest LimitedPrivate in my original, but this >>>>>>>> doesn't >>>>>>>> make >>>>>>>> sense as we're exposing Public API via CellUtil. >>>>>>>> >>>>>>>> It seems odd to me that we wouldn't treat the cell tags as a >>>>>>>> supported >>>>>>>> API >>>>>>>> call. However, I'm happy to remain "confused" if the rest of folks >>>>>>>> >>>>>>> don't >>>>> >>>>>> consider tags to be intended for users :) >>>>>>>> >>>>>>>> >>>>>>>> On 9/21/17 3:15 PM, Ted Yu wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Can we mark Tag LimitedPrivate ? >>>>>>>>> >>>>>>>>> We know how ATS uses Tags so it should be straight forward to keep >>>>>>>>> >>>>>>>> their >>>>> >>>>>> usage intact. >>>>>>>>> >>>>>>>>> On Thu, Sep 21, 2017 at 12:03 PM, Josh Elser <els...@apache.org> >>>>>>>>> >>>>>>>> wrote: >>>>> >>>>>> >>>>>>>>> Hiya, >>>>>>>>>> >>>>>>>>>> (Background, I'm starting what is likely to be an onerous task of >>>>>>>>>> looking >>>>>>>>>> through downstream components and seeing what is broken with the >>>>>>>>>> >>>>>>>>> latest >>>>> >>>>>> hbase-2.0.0*) >>>>>>>>>> >>>>>>>>>> Looking at YARN's use of HBase for the Application >>>>>>>>>> TimelineServer, I >>>>>>>>>> see >>>>>>>>>> that they're relying on the Tag interface. >>>>>>>>>> >>>>>>>>>> Presently, Tag is marked as Private, yet we expose it via the >>>>>>>>>> Public >>>>>>>>>> CellUtil. >>>>>>>>>> >>>>>>>>>> My gut reaction is that we should bump Tag up Public since the >>>>>>>>>> intent >>>>>>>>>> is >>>>>>>>>> for downstream users to, ya know, use those Tags. Any objections? >>>>>>>>>> >>>>>>>>>> If we don't want to expose Tag, we should make a pass over the >>>>>>>>>> Public >>>>>>>>>> methods and mark them as Private (so not as to provide a Public >>>>>>>>>> >>>>>>>>> method >>>>> >>>>>> with >>>>>>>>>> Private objects). CellUtil#getTag(Cell, byte) would be one such >>>>>>>>>> example. >>>>>>>>>> >>>>>>>>>> - Josh >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
