Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HDDS-11587. Ozone Manager not processing file put requests with multi-tenancy enabled #7316

Merged
merged 2 commits into from
Nov 5, 2024
Merged

HDDS-11587. Ozone Manager not processing file put requests with multi-tenancy enabled #7316

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f62fd43
HDDS-11587. Ozone Manager not processing file put requests while enab…
ChenSammi Oct 15, 2024
df2b313
address comment
ChenSammi Oct 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions .../java/org/apache/hadoop/ozone/om/multitenant/RangerClientMultiTenantAccessController.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,9 +130,15 @@ public RangerClientMultiTenantAccessController(OzoneConfiguration conf)

LOG.info("authType = {}, login user = {}", authType, usernameOrPrincipal);

client = new RangerClient(rangerHttpsAddress,
authType, usernameOrPrincipal, passwordOrKeytab,
rangerServiceName, OzoneConsts.OZONE);
UserGroupInformation loginUser = UserGroupInformation.getLoginUser();
try {
client = new RangerClient(rangerHttpsAddress,
authType, usernameOrPrincipal, passwordOrKeytab,
rangerServiceName, OzoneConsts.OZONE);
} finally {
// set back the expected login user
UserGroupInformation.setLoginUser(loginUser);
}
Comment on lines +133 to +141
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Sammi. Good catch.

From what I understand of HDDS-11587 description, RangerClient shares the same UserGroupInformation context with its caller (OM in this case).

Thus, when RangerClient's internal Kerberos login logic generated a new UGI and replaces the caller's LoginUser UGI, which causes the breakage (OM stuck, failed to re-login after a while).

Questions for Ranger folks: @kumaab

  1. What happens when RangerClient's UGI Kerberos login expires as well? My concern is, if RangerClient re-login using similar logic, the RangerClient instance can get stuck for the same reason as well? Or if RangerClient sets UGI again (haven't checked the impl), the OM could get stuck again for the same reason.
  2. Is there a way to isolate RangerClient's internal UserGroupInformation so that it doesn't leak out? Or, is it feasible to share the same UGI with caller?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a "RangerTagRefresher" thread which will periodically do kerberos relogin before ticket expiry. It doesn't call setLoginUser(). So OM will not stuck again.
Actually I checked two different Ranger versions, in one version setLoginUser is not called during RangerClient(). I'm curious for what purpose this setLoginUser is introduced.


// Whether or not the Ranger credentials are valid is unknown right after
// RangerClient initialization here. Because RangerClient does not perform
Expand Down