Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
From: Andrew Purtell <andrew.purtell@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Sat, 28 Oct 2017 18:24:32 -0700
Subject: Re: [DISCUSS] What we expect in upgrades to HBase 2.0.0
Message-Id: <C37A6FA4-D117-4154-B276-81E85103B663@gmail.com>
References: <CAN5cbe4r7Gt3_FWRWnDaon3shPY0QaZBWGOCQ+UApqYRNXUUPQ@mail.gmail.com> <CAN5cbe7FcFzCi20jjgMLSQ_prwVSz2wwMBEJPF9_cnQuTnkbaA@mail.gmail.com> <CAFAMeYLe9r6Gz_VYCV3DyXPB4orp039A-0cp-Rp+nCpwCaiR0Q@mail.gmail.com> <C00EC7F6-CF2B-45F5-8DAD-7305D6EA38B2@gmail.com> <aef46931-d496-3634-5a9d-98b1878cab46@gmail.com> <CAFAMeYKNXPAZv=+eKXc8a1HZ+mLFWV3qxQZpvspjnnQStm2_eQ@mail.gmail.com>
In-Reply-To: <CAFAMeYKNXPAZv=+eKXc8a1HZ+mLFWV3qxQZpvspjnnQStm2_eQ@mail.gmail.com>
To: dev@hbase.apache.org
archived-at: Sun, 29 Oct 2017 01:24:54 -0000

Is there anything in 1.4* not in 1.2 that would warrant that? Otherwise I ag=
ree, not requiring an intermediate upgrade step would be best. Requiring a d=
ouble upgrade would be super operator unfriendly.

* - Should everything go reasonably well we will have a 1.4.0 release before=
 December. I'm going to do the first RC next week.=20


> On Oct 28, 2017, at 5:09 PM, Mike Drob <madrob@cloudera.com> wrote:
>=20
> Ok, looks like there is some enough feelings that we don't need to worry
> about downgrades.
>=20
> What about the other part of Sean's question? Do we need to support rollin=
g
> upgrades to 2.0 from any 1.x, or is it fair game to require a specific
> minimum version?
>=20
> If we felt that it simplified things, I'd even be happy with a minimum
> 1.4->2.0 upgrade path, but 1.4 doesn't exist yet and I don't feel like
> that's something we can dictate to users. Maybe it's ok to set the minimum=

> line at 1.2? If we end up moving the stable pointer, that makes for a
> stronger argument for a newer minimum version.
>=20
> Mike
>=20
>> On Sat, Oct 28, 2017 at 4:46 PM, Josh Elser <josh.elser@gmail.com> wrote:=

>>=20
>> +1 -- well put, Andrew.
>>=20
>>=20
>>> On 10/28/17 1:17 PM, Andrew Purtell wrote:
>>>=20
>>> I would not like to see downgrades as a goal. This would be new. We've
>>> not done it before. Laudible goal, but we are clearly stretched already.=

>>>=20
>>>=20
>>>> On Oct 28, 2017, at 10:08 AM, Mike Drob <mdrob@apache.org> wrote:
>>>>=20
>>>> If downgrades are a later goal, does that mean somebody could go from
>>>> some
>>>> 1.x to 2.0 to 2.y then back to 1.x?
>>>>=20
>>>>> On Fri, Oct 27, 2017 at 10:42 PM, Sean Busbey <busbey@apache.org> wrot=
e:
>>>>>=20
>>>>> I'd like to make downgrades a non-goal. I'd love us to support
>>>>> downgrades eventually, but that's a feature in its own right and I
>>>>> don't think we have time to get it done and still have a 2.0.0 GA in a=

>>>>> reasonable time frame.
>>>>>=20
>>>>> On Fri, Oct 27, 2017 at 10:40 PM, Sean Busbey <busbey@apache.org>
>>>>>> wrote:
>>>>>> A recent JIRA about our hfile format[1] has got me thinking about
>>>>>> expectations for upgrading. The specifics of that JIRA aren't terribl=
y
>>>>>> important; it's the general issue I want to talk about. A
>>>>>> simplification of the mismatch in expectations between two groups is
>>>>>> that some folks place the bar for "we support rolling upgrade" at
>>>>>> rolling upgrade from 1.y.z* versions generally and others are
>>>>>> comfortable requiring an initial upgrade to some later 1.y.z version
>>>>>> first.
>>>>>>=20
>>>>>> Have we documented what our goals are for upgrades this major release=
?
>>>>>> Do we know what we have to do to get there? I've seen a few one-off
>>>>>> JIRAs to fix particular problems, but not really a plan.
>>>>>>=20
>>>>>> We should discuss here a bit.
>>>>>>=20
>>>>>> When things have some consensus is anyone willing to take point on
>>>>>> writing up the results in a scope document of sorts? I have a few goo=
d
>>>>>> examples to point you to, though they're all for features.
>>>>>>=20
>>>>>>=20
>>>>>> [1]: https://issues.apache.org/jira/browse/HBASE-19052
>>>>>>=20
>>>>>=20
>>>>>=20