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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *To:* Andrew Purtell <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc:* "[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>; lars hofhansl < > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>; > James Taylor <[email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > >>> To: "[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>; lars hofhansl < > >>> [email protected] <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > >>>> To: "[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] > <javascript:_e(%7B%7D,'cvml','[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 > >>> > >>> > > >
