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 >> >> >> >>
