hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <olorinb...@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Thu, 03 Jul 2014 19:25:21 GMT
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.
 - 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.

Thoughts?

Thanks,
Mikhail


2014-06-02 13:00 GMT-07:00 Jimmy Xiang <jxiang@cloudera.com>:

> For ZK-less assignment, I prefer it to go in before 1.0.  It's backward
> compatible and rolling-upgradable.
>
> I am doing more testing now.
>
> Thanks,
> Jimmy
>
>
> On Mon, Jun 2, 2014 at 12:54 PM, Mikhail Antonov <olorinbant@gmail.com>
> wrote:
>
> > On ZK abstraction...
> >
> > What date tentatively we're talking as a release date for 1.0.0?
> >
> > I think Enis is right that technically as long as we're just changing
> > private interfaces, we can do part in one release and the rest in
> > subsequent one, yet also I agree with Andrew that having ZK
> > partially-separated is a bit odd. On other consideration is that we can't
> > do anything non-rolling-upgradable before 1.0 is out, IIUC.
> >
> > I would say - let's aim to have not-too-intrusive refactoring work as
> part
> > of 1.0 (non-intrusive means - not changing control flow through ZK or
> data
> > stored in ZooKeeper). If we end up in in situation when ZK abstraction is
> > on the critical part for release - let's reduce the scope and leave
> certain
> > areas (like replication queues) for the subsequent release. And from 1.0
> > onwards - we can start redesigning the way we store shared state and
> tackle
> > multiple active master/region replicas.
> >
> > Thoughts?
> >
> > Jimmy - what about ZK-less assignment, will it go in before 1.0?
> >
> > -Mikhail
> >
> >
> >
> >
> >
> > 2014-06-02 11:49 GMT-07:00 Andrew Purtell <apurtell@apache.org>:
> >
> > > On Mon, Jun 2, 2014 at 11:43 AM, Enis Söztutar <enis.soz@gmail.com>
> > wrote:
> > >
> > > > On Mon, Jun 2, 2014 at 10:25 AM, Andrew Purtell <apurtell@apache.org
> >
> > > > wrote:
> > > >
> > > > > An email from JIRA reminds me that we should also have the
> ZooKeeper
> > > > > related refactoring complete in 1.0 before releasing it. That work
> is
> > > > > pretty far along and needs all bits in place to be useful.
> > > > >
> > > >
> > > > Agreed that it will be good to get this completed. However, they are
> > > mostly
> > > > internal interfaces and I am not sure whether all the changes
> required
> > > will
> > > > be done in time. We can continue on this even after 1.0, no?
> > >
> > >
> > > ​I think it would be weird to have a release where we are partially on
> > the
> > > way to plugging ZooKeeper in and out but not all the way, so that's not
> > > actually possible.​
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
> >
>



-- 
Thanks,
Michael Antonov

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