Duo Zhang created HBASE-28326:
-
Summary: All nightly jobs are failing
Key: HBASE-28326
URL: https://issues.apache.org/jira/browse/HBASE-28326
Project: HBase
Issue Type: Bug
Components:
Thanks for the suggestion.
We can do this check, in HBase we only have two roles to connect,
either master or region server, the only problem here is that we do
not know whether it is a master or region server, so after getting the
server principal, we could check whether it matches the master
Hi folks,
I have experience enabling secure mode (Kerberos) for the HDFS layer on all
of Hubspot's HBase clusters. The pattern in the Hadoop project is for
clients to know what principal, or principal pattern, to expect a server to
present. For example, see
Would love another discuss thread on that tangent, because I completely
agree and think it warrants some discussion.
In terms of the original takeaways here, I'm now auditing the jiras which
have fixVersion = 2.6.0 but which existed in branch-2.5 prior to the
release of 2.5.0. There are only 31
I’m late to the discussion, but you’ve concluded on what I believe is the
correct approach. Another way to consider why this approach is correct is
to think in terms of “git time” instead of chronological time. Consider the
last common ancestor commit in the git histories. branch-2.6 was created
[
https://issues.apache.org/jira/browse/HBASE-28302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault resolved HBASE-28302.
---
Fix Version/s: 2.6.0
3.0.0-beta-2
Release Note: Adds a new
[
https://issues.apache.org/jira/browse/HBASE-27966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault resolved HBASE-27966.
---
Resolution: Fixed
Pushed to branch-3. Test looks good there. I quickly checked the
[
https://issues.apache.org/jira/browse/HBASE-27966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault reopened HBASE-27966:
---
Re-opening because I just realized that this was not included in branch-3.
Perhaps it
Thanks Bryan.
If no other concerns, let me at least re-implement the PR for
HBASE-25051 based on the approach proposed here.
Bryan Beaudreault 于2024年1月23日周二 21:40写道：
>
> Thanks for pulling this together Duo. I'll take a closer look at this after
> I finish up the 2.6.0 release.
>
> To me the
Thanks for pulling this together Duo. I'll take a closer look at this after
I finish up the 2.6.0 release.
To me the only possibly controversial part is:
> For HBASE-28321, it should be part of our rpc negotiation, where the
server should return its server principal to the client, to let the
[
https://issues.apache.org/jira/browse/HBASE-28325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reopened HBASE-28325:
--
I don't want a comment for every PR comment, only a comment when the PR is
detected/linked.
Thanks for the history dive :)
> but not all the commits in 2.5.1 will go into 2.6.0, even if 2.6.0 is
released after 2.5.1.
I actually had the same thought after sending my last response. There might
also be bug fixes that only apply to 2.5.x. This, along with historical
convention, seems like
I checked the history a bit...
For 2.0.0, the previous version is 1.0.0...
https://github.com/apache/hbase/blob/branch-2.0/CHANGES.md
For 2.1.0 and 2.2.0, we do not include the previous version in the
CHANGES.md, but you can pick some issues, usually it will have a 2.0.x
or 2.1.x fix versions.
Thanks again for the back and forth here, both. It seems like there is no
single right solution, which in my opinion is not great. It’s
understandable though because historically it’s been hard to enforce a
standard.
The release process is involved but largely automated. One piece not
automated
Nick Dimiduk created HBASE-28325:
Summary: Enable infra automation to comment on a Jira when a new
PR is posted.
Key: HBASE-28325
URL: https://issues.apache.org/jira/browse/HBASE-28325
Project: HBase
15 matches
Mail list logo
