hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSS] What we expect in upgrades to HBase 2.0.0
Date Mon, 30 Oct 2017 05:35:09 GMT
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