I agree with Andrew that we can't both have maintenance releases and expect
every feature in ongoing branch-1 releases to be in branches-2.y.
Tracking consideration for when features are available across major
versions fits in well with the "upgrade paths" section in the ref guide.
We've just
Duo Zhang created HBASE-21746:
-
Summary: RegionMover.stripServer will return the last server if
the target server does not exist
Key: HBASE-21746
URL: https://issues.apache.org/jira/browse/HBASE-21746
Then we must have a upgrade path, for example, 1.5.x can only be upgraded
to 2.2.x if you want all the features still there?
Maybe we should have a release timeline for the first release of all the
minor releases? So when user want to upgrade, they can choose the minor
release which is released
Also I think branch-1 releases will be done on a monthly cadence independent of
any branch-2 releases. This is because there are different RMs at work with
different needs and schedules.
I can certainly help out some with branch-2 releasing if you need it, FWIW.
It may also help if we begin
Also please be prepared to support forward evolution and maintenance of
branch-1 for, potentially, years. Because it is used in production and will
continue to do so for a long time. Features may end up in 1.6.0 that only
appear in 2.3 or 2.4. And in 1.7 that only appear in 2.5 or 2.6. This
This can't work, because we can put things into a new minor that cannot go into
a patch relesse. If you say instead 2.2.0 must have everything in 1.5.0, it can
work. The alignment of features should happen at the minor releases. If we can
also have alignment in patch releases too, that would be
And yes we should document this.
And also we need to have a web page to list all the releases in timeline?
So user could know which version is safe to use when upgrading easily.
张铎(Duo Zhang) 于2019年1月19日周六 上午11:12写道：
> Please see the red words carefully, I explicitly mentioned that, the newer
Please see the red words carefully, I explicitly mentioned that, the newer
version should be released LATER, if you want to get all the features.
For example, you release 2.1.0 yesterday, 1.5.0 today, and then 2.1.1
tomorrow, it is OK that 2.1.0 does not have all feature which 1.5.0 has,
but
Consider that we actually cannot guarantee this without a time machine, because
some "newer" versions are already released.
If we backport to 1.5 now, we cannot do anything about 2.0.0, 2.1.0, 2.1.2,
etc. because they are already released... if the user upgrades from 1.5 to
2.0.1 for example,
https://issues.apache.org/jira/browse/HBASE-21745
张铎(Duo Zhang) 于2019年1月19日周六 上午9:51写道：
> OK, the original issue is HBCK2 for AMv2, but here we need to do more, not
> only for AMv2.
>
> Let me open a new issue and post what Andrew said above there.
>
> 张铎(Duo Zhang) 于2019年1月19日周六 上午9:26写道：
>
Duo Zhang created HBASE-21745:
-
Summary: Make HBCK2 be able to fix issues other than region
assignment
Key: HBASE-21745
URL: https://issues.apache.org/jira/browse/HBASE-21745
Project: HBase
OK, the original issue is HBCK2 for AMv2, but here we need to do more, not
only for AMv2.
Let me open a new issue and post what Andrew said above there.
张铎(Duo Zhang) 于2019年1月19日周六 上午9:26写道：
> OK, let me find the original HBCK2 issue and see how can we make progress
> on it.
>
> BTW, on scan
I think we have a good discussion on HBASE-21034, where a feature is back
ported to branch-1, but then folks think that we should not back port them
to branch-2.1 and branch-2.0, as usually we should not add new features to
minor release lines.
I think the reason why we do not want the feature in
OK, let me find the original HBCK2 issue and see how can we make progress
on it.
BTW, on scan performance, Zheng Hu has done a work to get about 40%
performance back in this issue for 100% scan case on ycsb
https://issues.apache.org/jira/browse/HBASE-21657
Andrew Purtell 于2019年1月19日周六
Sergey Shelukhin created HBASE-21744:
Summary: timeout for server list refresh calls
Key: HBASE-21744
URL: https://issues.apache.org/jira/browse/HBASE-21744
Project: HBase
Issue Type:
Lars was testing tip of branch-2 with Phoenix and said scans were 50%
slower than branch-1. I’ll try and get him to provide more details. Anyway
after hbck2 is complete issues like that will come out in the testing we’d
do as part of sanity checking a move of the pointer.
On Fri, Jan 18, 2019 at
Sergey Shelukhin created HBASE-21743:
Summary: stateless assignment
Key: HBASE-21743
URL: https://issues.apache.org/jira/browse/HBASE-21743
Project: HBase
Issue Type: Bug
I agree with the sentiment around HBCK2. I think these kind of recovery
tools are essential before marking something stable.
I also remember when we did testing around HBase 2.x/2.1 that we were
getting perf degradations and couldn't seem to get performance to be as
good as we were getting in the
Sergey Shelukhin created HBASE-21742:
Summary: master can create bad procedures during abort, making
entire cluster unusable
Key: HBASE-21742
URL: https://issues.apache.org/jira/browse/HBASE-21742
Sakthi created HBASE-21741:
--
Summary: Add a note in "HFile Tool" section regarding 'seqid=0'
Key: HBASE-21741
URL: https://issues.apache.org/jira/browse/HBASE-21741
Project: HBase
Issue Type:
Sent.
On Fri, Jan 18, 2019 at 7:48 AM Abhishek Gupta wrote:
> Hi,
>
> I would like an invitation too abhila...@gmail.com
>
> Thanks
>
> On Fri, Jan 18, 2019 at 11:38 AM Manjeet Singh >
> wrote:
>
> > Done
> >
> > On Fri, 18 Jan 2019, 11:24 Buchi Reddy Busi Reddy > wrote:
> >
> > > Can you
Invitation has been sent.
Best,
Balazs
On Fri, Jan 18, 2019 at 6:48 AM aman goyal wrote:
> Hi Team,
>
> Pls provide access to hbase user slack channel
> https://apache-hbase.slack.com
>
> Pls send invitation to aman...@gmail.com
>
> Thanks,
> Aman
>
lujie created HBASE-21740:
-
Summary: NPE happens while shutdown the RS
Key: HBASE-21740
URL: https://issues.apache.org/jira/browse/HBASE-21740
Project: HBase
Issue Type: Bug
Reporter:
23 matches
Mail list logo
