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