The vote for the release of Apache Phoenix 4.2.1 RC1 is now closed and
has passed with 4 binding +1s and no 0 or -1s:
Jeffrey Zhong*
Gabriel Reid*
Steven Noels*
James Taylor*
*=binding
We'll push out the new release to maven. Thanks to those who voted.
James
On Mon, Nov 17, 2014 at 9:26 PM, James Taylor <[email protected]> wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
