That's an excellent suggestion: Ship 4.2.1 with salt buckets set to 0. Than
users can change that setting when/where desired.
-- Lars
From: Jeffrey Zhong <[email protected]>
To: [email protected]; Andrew Purtell <[email protected]>
Cc: lars hofhansl <[email protected]>; James Taylor <[email protected]>
Sent: Sunday, November 16, 2014 11:34 AM
Subject: Re: [VOTE] Release of Apache Phoenix 4.2.1 RC1
One option I¹m thinking of is that we can document this as a release note
for 4.2:
If a user needs to have rolling upgrade, s/he can set
³phoenix.sequence.saltBuckets² to 0 otherwise to 4.2+ upgrade needs to
stop all old clients before a 4.2+ client connect to a Phoenix cluster.
Since changing ³phoenix.sequence.saltBuckets² isn¹t support in rolling
restart fashion, we could not upgrade bits firstly then bumping up the
config setting. In the future release, we should pay more attention on the
schema change & possible upgrade compatibility issues. We could leverage
the related
doc(https://docs.google.com/a/hortonworks.com/document/d/1p5pP7v2OuzSSaomK2
S2v7sfKky1Hex6OqwsJO0sZTUY/edit) on Hbase by Lars.
Thanks,
-Jeffrey
On 11/16/14, 9:54 AM, "James Taylor" <[email protected]> wrote:
>@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
>>>>
>>>>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
