hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Mon, 07 Jul 2014 19:24:47 GMT
We're on the same page, Enis.

Cheers


On Mon, Jul 7, 2014 at 10:56 AM, Enis Söztutar <enis@apache.org> wrote:

> 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