hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: DISCUSSION: 1.0.0
Date Mon, 07 Jul 2014 17:56:11 GMT
I think it is fair to say for both C API and transaction API that it should
be ok to include them if they are ready before the time to cut the 1.0 RC.
If not, I do not want to hold the release waiting for those.

Enis


On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <andrew.purtell@gmail.com>
wrote:

> And by definition of that being a proposed design, there is no
> implementation to track (yet). There being no implementation, it's hard to
> see how it makes a 1.0 happening "soon".
>
> Don't misunderstand me to be opposed to the idea or feature, far from it.
> I don't think Ted did anyone a service bringing it up in the context of
> 1.0. Already we are on some kind of detour from discussing things where
> there are patches available.
>
>
> > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <olorinbant@gmail.com>
> wrote:
> >
> > I thought the scope of HBASE-11447 is to review and refine proposed
> design,
> > not to track the implementation of the feature?
> >
> > -Mikhail
> >
> >
> > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <andrew.purtell@gmail.com>:
> >
> >> That is not a realistic proposal for 1.0 as far as I can see. There is
> >> only a tentative design spec on that issue. I assume we are sticking
> with
> >> Enis' earlier stated intent to get 1.0 out "soon".
> >>
> >>
> >>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yuzhihong@gmail.com> wrote:
> >>>
> >>> The following is another candidate for 1.0.0 release
> >>>
> >>> HBASE-11447 Proposal for a generic transaction API for HBase
> >>>
> >>> Cheers
> >>>
> >>>
> >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <adityakishore@gmail.com>
> wrote:
> >>>>
> >>>> Do we want to have the C APIs part of 1.0.0 release. I had posted few
> >>>> patches and a set of review request sometime last week.
> >>>>
> >>>>
> >>>>> On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis.soz@gmail.com>
> >> wrote:
> >>>>>
> >>>>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <
> olorinbant@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Moved ZK watcher & listener subtask out of scope HBASE-10909.
Enis -
> >>>> with
> >>>>>> that, I guess HBASE-10909 can be marked in branch-1?
> >>>>>
> >>>>> Sounds good.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> HBASE-11464 - this is the jira where I'll capture tasks to abstract
> >>>> hbase
> >>>>>> client from ZK (mostly it would be post-1.0 work).
> >>>>>
> >>>>> Not sure whether we can make it fully backwards compatible with
1.0
> >>>>> clients. I guess we will see when the patches are done.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Mikhail
> >>>>>>
> >>>>>>
> >>>>>> 2014-07-03 12:52 GMT-07:00 Stack <stack@duboce.net>:
> >>>>>>
> >>>>>>> On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <
> >>>> olorinbant@gmail.com
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Guys,
> >>>>>>>>
> >>>>>>>> getting back to ZK abstraction work w.r.t. release 1.0
and
> >>>>> thereafter,
> >>>>>>> some
> >>>>>>>> status update. So as we're getting closer to complete
HBASE-10909,
> >>>> it
> >>>>>>> looks
> >>>>>>>> like the steps may be like this:
> >>>>>>>>
> >>>>>>>> - there are 2 subtasks out there not closed yet, one
of which is
> >>>>> about
> >>>>>>> log
> >>>>>>>> splitting (and Sergey S has submitted a patch for review),
another
> >>>> is
> >>>>>>>> abstraction of ZK watcher (this is what I've been working
on in
> the
> >>>>>>>> background; but after sketching the patch it seems like
without
> >>>> being
> >>>>>>> able
> >>>>>>>> to modify the control flows and some changes in the
module
> >>>> structure,
> >>>>>>> it'd
> >>>>>>>> be a lot of scaffolding code not really simplifying
current code).
> >>>> So
> >>>>>> I'd
> >>>>>>>> propose to descope abstraction of ZK watcher jira (HBASE-11073),
> >>>>>> namely:
> >>>>>>>> convert it to top-level JIRA and continue to work on
it
> separately;
> >>>>>>> rename
> >>>>>>>> HBASE-10909 to "ZK abstraction: phase 1", and mark it
as closed as
> >>>>> soon
> >>>>>>> as
> >>>>>>>> log splitting jira is completed. This way HBASE-10909
fits to
> >>>>> branch-1.
> >>>>>>>
> >>>>>>> Sounds good to me.
> >>>>>>>
> >>>>>>>
> >>>>>>>> - secondly, in the discussion to the CatalogTracker
patch, we
> >>>>> started
> >>>>>>>> talking about modifying client to not know about ZK,
but rather
> >>>> keep
> >>>>>> the
> >>>>>>>> location of current masters and talk to them using RPC
calls. This
> >>>>> work
> >>>>>>> can
> >>>>>>>> not go into branch-1, as it involves invasive changes
in client
> >>>>>> including
> >>>>>>>> new RPC. As I understand the branching schema now, those
changes
> >>>> can
> >>>>> go
> >>>>>>> to
> >>>>>>>> master branch, we just don't merge them to branch-1,
and depending
> >>>> on
> >>>>>>> their
> >>>>>>>> completeness we can pull them to 1.1 release or so.
> >>>>>>>
> >>>>>>> You have it right Mikhail.
> >>>>>>>
> >>>>>>> St.Ack
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Thanks,
> >>>>>> Michael Antonov
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message