My vote is +1. Thanks, James
On Mon, Nov 17, 2014 at 8:16 PM, lars hofhansl <[email protected]> wrote: > Fair enough. Thanks Gabriel. > Despite what has been suggested I have not actually -1'd the release:>> Let's > discuss, I won't -1 the RC until we do. > > It seems we had some discussion now.I still think we should follow the path > of the least surprise to the users, consequently I will abstain from the > vote.I will say that in the time we took for this discussion we could have > spun and announced a new RC for 4.2.1. > > Let's have a release note saying that when coming from 4.1 to set > phoenix.sequence.saltBuckets=0 when using sequences in a mixed 4.1 and 4.2 > client environment.(looked at the code and confirmed that that would work) > > I'm happy to draft the release note. > > -- Lars > > From: Gabriel Reid <[email protected]> > To: [email protected] > Sent: Monday, November 17, 2014 1:22 PM > Subject: Re: [VOTE] Release of Apache Phoenix 4.2.1 RC1 > > Sorry I'm late to weigh in on this. So from what I understand, the > backwards compatibility issue (which is in line with how backwards > compatibility has been done up until now) is present in 4.2 and the > 4.2.1 RCs. > > If that is indeed the case (and from what I read earlier in this > thread, it is the case), then it does indeed seem somewhat wasteful to > sink the RC to handle backwards compat differently than something > that's already out in the wild (i.e. the 4.2 release). I think it's > definitely something worth making clear in a release note, but anyone > who has already started using 4.2 isn't going to be helped by further > delays on 4.2.1, but they are going to have be disadvantaged by having > to wait longer for all the bug fixes in 4.2.1. I think that I would > think differently about this if this discussion were going on for the > 4.2 RC, but that isn't the case here. > > - Gabriel > > > > > > On Sun, Nov 16, 2014 at 11:22 PM, James Taylor <[email protected]> wrote: >> 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 >>>>> >>>>> >>>>> >>>>> > > >
