hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] What we expect in upgrades to HBase 2.0.0
Date Mon, 30 Oct 2017 20:51:46 GMT
Ok, then it's covered.

On Sun, Oct 29, 2017 at 10:35 PM, Stack <stack@duboce.net> wrote:

> I was going to do 1.2...
> S
>
> On Sun, Oct 29, 2017 at 9:52 AM, Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
>
> > I'll check how upgrade fares from 1.4 to 2.0 while exercising the 1.4.0
> > candidates for release. Can someone do that for 1.2?
> >
> >
> > > On Oct 29, 2017, at 9:11 AM, Mike Drob <mdrob@apache.org> wrote:
> > >
> > > I think the crux of the issue is that nobody's done the work to find
> out.
> > >
> > > On Sat, Oct 28, 2017 at 8:24 PM, Andrew Purtell <
> > andrew.purtell@gmail.com>
> > > wrote:
> > >
> > >> Is there anything in 1.4* not in 1.2 that would warrant that?
> Otherwise
> > I
> > >> agree, not requiring an intermediate upgrade step would be best.
> > Requiring
> > >> a double 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.
> > >>
> > >>
> > >>> On Oct 28, 2017, at 5:09 PM, Mike Drob <madrob@cloudera.com>
wrote:
> > >>>
> > >>> Ok, looks like there is some enough feelings that we don't need to
> > worry
> > >>> about downgrades.
> > >>>
> > >>> What about the other part of Sean's question? Do we need to support
> > >> rolling
> > >>> upgrades to 2.0 from any 1.x, or is it fair game to require a
> specific
> > >>> minimum version?
> > >>>
> > >>> 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.
> > >>>
> > >>> Mike
> > >>>
> > >>>> On Sat, Oct 28, 2017 at 4:46 PM, Josh Elser <josh.elser@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> +1 -- well put, Andrew.
> > >>>>
> > >>>>
> > >>>>> On 10/28/17 1:17 PM, Andrew Purtell wrote:
> > >>>>>
> > >>>>> 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.
> > >>>>>
> > >>>>>
> > >>>>>> On Oct 28, 2017, at 10:08 AM, Mike Drob <mdrob@apache.org>
wrote:
> > >>>>>>
> > >>>>>> 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?
> > >>>>>>
> > >>>>>>> On Fri, Oct 27, 2017 at 10:42 PM, Sean Busbey <busbey@apache.org
> >
> > >> wrote:
> > >>>>>>>
> > >>>>>>> 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.
> > >>>>>>>
> > >>>>>>> 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
> > >> terribly
> > >>>>>>>> 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.
> > >>>>>>>>
> > >>>>>>>> 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.
> > >>>>>>>>
> > >>>>>>>> We should discuss here a bit.
> > >>>>>>>>
> > >>>>>>>> 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
> > >> good
> > >>>>>>>> examples to point you to, though they're all for
features.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> [1]: https://issues.apache.org/jira/browse/HBASE-19052
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message