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 <apurt...@apache.org>: > On Mon, Jun 2, 2014 at 11:43 AM, Enis Söztutar <enis....@gmail.com> wrote: > > > On Mon, Jun 2, 2014 at 10:25 AM, Andrew Purtell <apurt...@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
