@Lars:
you are correct that this would break compatibility between {0.94.0,
0.94.1} and 0.94.2.We clearly need better compatibility testing, these issues are hard to find by just looking at patches. Greg On Fri, Aug 31, 2012 at 4:03 PM, Ted Yu <[email protected]> wrote: > I should also apologize for HBASE-5206 where I didn't maintain > compatibility in the first place. > > We just need to find the solution which minimizes impact of this issue. > > Cheers > > On Fri, Aug 31, 2012 at 3:55 PM, lars hofhansl <[email protected]> > wrote: > > > Won't we then break compatibility between 0.94.0 and 0.94.1 with 0.94.2? > > I do not have a strong opinion about this. > > > > It was my fault that HBASE-5206 slipped into 0.94.0, I apologize for > that. > > > > I was going to spin the first 0.94.2 today. Is the general consensus that > > I should wait? > > > > > > -- Lars > > > > > > > > ________________________________ > > From: Gregory Chanan <[email protected]> > > To: [email protected] > > Sent: Friday, August 31, 2012 3:13 PM > > Subject: 0.92/0.94 compatibility and HBASE-5206 > > > > There has been some discussion on the JIRA lately about what to do about > a > > 0.92/0.94 compatibility issue. I wanted to bring this up to a larger > > audience in order to solicit additional opinions. > > > > HBASE-5206 (https://issues.apache.org/jira/browse/HBASE-5206), which is > in > > 0.94.0 and 0.94.1, breaks compatibility with 0.92.0 and 0.92.1. The > issue > > is described in the release notes for HBASE-5155 (of which HBASE-5206 is > a > > forward port). Excerpted here: > > > > This issue is an incompatible change. > > If an HBase client with the changes for HBASE-5155 and a server > (master) > > without the changes for HBASE-5155 is used, then the is_enabled (from > HBase > > Shell) or isTableEnabled() (from HBaseAdmin) will return false though the > > table is already enabled as per the master. > > > > If the HBase client does have the changes for HBASE-5155 and the server > > does not have the changes for HBASE-5155, then if we try to Enable a > table > > then the client will hang. > > > > The reason is because, > > Prior to HBASE-5155 once the table is enabled the znode in the > zookeeper > > created for the table is deleted. > > After HBASE-5155 once the table is enabled the znode in the zookeeper > > created for the table is not deleted, whereas the same node is updated > with > > the status ENABLED. > > > > The client also expects the status of the znode in the zookeeper to be > in > > the ENABLED state if the table has been enabled successfully. > > The above changes makes the client behaviour incompatible if the client > > does not have this fix whereas the server has this fix. > > If both the client and the server does not have this fix, then the > > behaviour is as expected. > > > > So we have a situation where 0.92.0 and 0.92.1 clients are not compatible > > with 0.94.0 and 0.94.1 servers and visa-versa. > > > > The issue is, what should we do about the 0.94.2 server? As far as I can > > tell, we cannot make both {0.92.0,0.92.1} and {0.94.0,0.94.1} clients > > happy. I propose we make the 0.94.2 server compatible with the {0.92.0, > > 0.92.1} client set. My thinking is that we should optimize for the most > > common use case. Given that both CDH4 and HDP 1.0 ship 0.92.1, and that > > 0.94 is relatively new, it seems more likely that users will upgrade > > servers from 0.92.1 to 0.94.2+ than from an earlier 0.94 version. I > think > > we can do this while actually fixing the issue that HBASE-5206 purports > to > > fix by moving the ENABLED state to a different znode. I'll even > volunteer > > to do that :). I don't think there is an obvious or easy answer here, so > > wanted to get other's opinions. > > > > As for the client, HBASE-6268 ( > > https://issues.apache.org/jira/browse/HBASE-6268) was introduced in > 0.92.2 > > to handle both cases of servers ({0.92.0,0.92.1} and {0.94.0,0.94.1}) by > > accepting both possibilities for the table znode. I think that approach > > works whether we leave the server as is or go with what I've proposed -- > > but we should test. > > > > Greg >
