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