I think that is a reasonable set of steps to take. We'd only disable the upgrade code, perhaps with a configuration toggle that defaults to 'false'. Then anyone upgrading either from 4.1 or 4.2.0 to 4.2.1 will be ok, and if coming from 4.1, mixed 4.1 and 4.2.1 clients will be fine.
> On Nov 16, 2014, at 1:40 PM, lars hofhansl <[email protected]> wrote: > > I did not mean to start a heated discussion, apologies for that. > > For the record, here is what I am suggesting: > > 1) remove or disable the SEQUENCE table upgrade for 4.2.1 > 2) put out a note that 4.2.0 has issues when you come from 4.1 and use > sequences, and to wait for 4.2.1 in that case > 3) (with that we have breathing room to) brainstorm upgrade procedures for > 4.2.2 or 4.3.x > > In my opinion this would be the best option. As usually, these are just my > $0.02. > > We can take it or leave it. :) > > Thanks. > > -- Lars > > From: James Taylor <[email protected]> > To: lars hofhansl <[email protected]> > Cc: "[email protected]" <[email protected]>; Andrew Purtell > <[email protected]>; James Taylor <[email protected]> > Sent: Sunday, November 16, 2014 11:48 AM > Subject: Re: [VOTE] Release of Apache Phoenix 4.2.1 RC1 > > Yes, 4.2 release already had the salting upgrade code for sequences. I'm not > opposed to changing our upgrade contract, but I'd like that to be done in a > follow up release. > > Thanks, > James > > On Sunday, November 16, 2014, lars hofhansl <[email protected]> wrote: > > > Does Phoenix 4.2.0 have the salting upgrade codle? If yes, I agree. If not, > there is no public release of Phoenix that has the upgrade code. > And here is my feedback with my Salesforce hat on: It breaks things! And it > leads to operational complexity and/or custom patches for us. > > Why are you opposed to even discussing a simple change (removal of a few > lines of code)? > > The pro is that upgrading from 4.1 is easier for large users, the con is that > now the sequence table will remain unsalted. These are the only relevant > points to discuss. > Let's weigh these pros/cons on their own merit and decide what we should do. > That is all that I am asking. > > -- Lars > > From: James Taylor <[email protected]> > To: Andrew Purtell <[email protected]> > Cc: "[email protected]" <[email protected]>; lars hofhansl > <[email protected]>; James Taylor <[email protected]> > Sent: Sunday, November 16, 2014 9:54 AM > Subject: Re: [VOTE] Release of Apache Phoenix 4.2.1 RC1 > > @Jesse - the sequence table was converted to being salted in the 4.2 > release which is already out. > > @Andrew - I like that idea - that would be an improvement. The > implementation might be tricky, depending on the type of upgrade > that's necessary to do. Let's discuss this for the next patch release > and come up with a plan. > > FWIW, Phoenix has does it's upgrade in same manner for all of its 20 > prior releases and we've never heard back from any of our users that > this is broken or not useful. The upgrade of the sequence table to be > salted is already released as of the 4.2 release, so holding up the > patch over this doesn't make sense. Can it be improved? Sure, but > that's not a reason to hold up this patch release with its 30 bug > fixes. > > Thanks, > James > > > > On Sat, Nov 15, 2014 at 6:33 PM, Andrew Purtell > <[email protected]> wrote: > > Can we just make auto schema upgrade configurable in general? Then this > > issue and others like it we might have going forward can be controlled. It > > should be possible to deploy 4.2 clients and have them run in "4.1 mode" > > until the fleet is ready for a cut over to a 4.2 schema upgrade... and same > > for any subsequent minor bump IMO. > > > > We should also have a discussion about what kind of major/minor/patch > > version compatibility expectations we want to and/or should set for users > > separate from this vote thread. > > > > > > > >> On Nov 15, 2014, at 6:24 PM, Jesse Yates <[email protected]> wrote: > >> > >> I dont think it is that unreasonable to not split the sequences table for a > >> release (this is the incompatible change, right?) to gain the ability to > >> mix 4.1 and 4.2 clients. > >> > >> Yes, its a new part of the compatibility story but honestly a necessity to > >> anyone looking to run phoenix in production without having a large number > >> of your clients all stop working at the same time. > >> > >> The question is, how critical is the incompatible feature? If its a big > >> deal, then we can cut a major release with it. If its a small segment of > >> use cases and some minor perf improvements, then I think we should push it. > >> In the between, then we should discuss (and talk to users about what they > >> want, because that's who we are developing for, in the end). > >> > >> We can figure out how to make it compatible in this release - simple flag > >> check should be sufficent in this case - and update our policy. > >> > >> Seems a lot to gain for not much cost. But maybe I'm missing something > >> > >> -j > >> > >>> On Sat, Nov 15, 2014, 6:00 PM lars hofhansl <[email protected]> wrote: > >>> > >>> This may work "as designed". but that does not make it _useful_. It is > >>> something new that we encountered that we did not think through. > >>> On whether it's a new requirement, that depends on what "backwards > >>> compatibility" means. > >>> If we say a 4.2 server is backwards compatible with a 4.1 client, we > >>> haven't really specified what that means.It is clear that 4.2 metadata > >>> does > >>> *not* work with a 4.1 client, but is that really useful then? It means any > >>> user would need to upgrade all their client at the exact same moment. > >>> If it matters, we can call it a "new requirement", and still do that in > >>> 4.2. The release is not out, so we can fix it now. > >>> > >>> This does break things, as we've seen. I would like to discuss it here. > >>> Since we did not finish voting - if we wanted to change this, now is the > >>> time. > >>> -- Lars > >>> > >>> From: James Taylor <[email protected]> > >>> To: "[email protected]" <[email protected]>; lars hofhansl < > >>> [email protected]> > >>> Sent: Saturday, November 15, 2014 5:45 PM > >>> Subject: Re: [VOTE] Release of Apache Phoenix 4.2.1 RC1 > >>> > >>> This works as designed. Supporting a mix of 4.1 and 4.2 clients has > >>> never been in our backwards compatibility contract. If we want to add > >>> this new requirement in 4.3, then that's fine, but let's at least be > >>> clear that this is a *new* requirement. > >>> > >>> James > >>> > >>> > >>> > >>>> On Sat, Nov 15, 2014 at 5:14 PM, lars hofhansl <[email protected]> wrote: > >>>> As we discovered at Salesforce, this breaks mixed 4.1 and 4.2 clients > >>> when those clients use sequences. As soon as the first 4.2 connects to a > >>> cluster upgraded to 4.2 the cluster's metadata is upgraded. At that point > >>> 4.1 clients using sequences are broken. > >>>> I propose we sink the RC, remove the upgrade code from 4.2, and push it > >>> to 4.3. That means the sequence table will not be pre-split in 4.2. > >>>> > >>>> Let's discuss, I won't -1 the RC until we do. > >>>> Thanks. > >>>> > >>>> -- Lars > >>>> From: James Taylor <[email protected]> > >>>> To: "[email protected]" <[email protected]> > >>>> Sent: Thursday, November 13, 2014 8:25 AM > >>>> Subject: [VOTE] Release of Apache Phoenix 4.2.1 RC1 > >>>> > >>>> Hello everyone, > >>>> > >>>> This is a call for a vote on Apache Phoenix 4.2.1 RC1. This is a bug > >>>> fix/patch release of Phoenix 4.2, compatible with the 0.98 branch of > >>>> Apache HBase with feature parity against the Phoenix 3.2 release. The > >>>> release includes both a source-only release and a convenience binary > >>>> release. > >>>> > >>>> The previous RC was sunk due to a backward compatibility issue and > >>>> various other bugs. > >>>> > >>>> For a complete list of changes, see: > >>>> https://raw.githubusercontent.com/apache/phoenix/4.2/CHANGES > >>>> > >>>> The source tarball, including signatures, digests, etc can be found at: > >>>> https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.1-rc1/src/ > >>>> > >>>> The binary artifacts can be found at: > >>>> https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.1-rc1/bin/ > >>>> > >>>> Release artifacts are signed with the following key: > >>>> https://people.apache.org/keys/committer/mujtaba.asc > >>>> > >>>> KEYS file available here: > >>>> https://dist.apache.org/repos/dist/release/phoenix/KEYS > >>>> > >>>> The hash and tag to be voted upon: > >>>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h= > >>> e00763ee0151518decc2db39b207a6e674c0eebb > >>>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag; > >>> h=refs/tags/v4.2.1-rc1 > >>>> > >>>> Vote will be open for at least 72 hours. Please vote: > >>>> > >>>> [ ] +1 approve > >>>> [ ] +0 no opinion > >>>> [ ] -1 disapprove (and reason why) > >>>> > >>>> Thanks, > >>>> The Apache Phoenix Team > >>> > >>> > > > >
