Jeffrey's response is here: http://s.apache.org/B5o
Any user who doesn't want the sequence table salted can add a phoenix.sequence.saltBuckets=0 in their hbase-sites.xml. I don't understand the idea of changing our backward compatibility contract mid-flight in a patch release . I think we should discuss that separately, after the release and all agree on it, rather than hold up a patch release. This upgrade meets the same backward compatibility contract as previous releases. On Sun, Nov 16, 2014 at 2:05 PM, Andrew Purtell <[email protected]> wrote: > Scanning backwards in this thread I don't see that. I guess it was in another > response. So can we set phoenix.sequence.saltBuckets to 0 by default then in > this release? > > > >> On Nov 16, 2014, at 2:02 PM, James Taylor <[email protected]> wrote: >> >> As Jeffrey pointed out, there's already a way to turn off the upgrade >> - just set the phoenix.sequence.saltBuckets to 0. >> >> The upgrade meets our current backward compatibility contract. Why >> would we vote down a patch release based on a proposed enhancement? >> >> James >> >> On Sun, Nov 16, 2014 at 1:55 PM, Andrew Purtell >> <[email protected]> wrote: >>> 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 >>> >>> >>> >>>
