Alexey Serbin has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/20514 )

Change subject: KUDU-3507 Fix mini ranger port detection
......................................................................


Patch Set 2:

(2 comments)

http://gerrit.cloudera.org:8080/#/c/20514/2//COMMIT_MSG
Commit Message:

http://gerrit.cloudera.org:8080/#/c/20514/2//COMMIT_MSG@10
PS2, Line 10: lsof might handle 0.0.0.0 as ipv6
> Yes. The utility function uses lsof. For example see test_utils.cc:467:
All right, I ran the test in my environment to see what's going on.  My 
analysis yields a different root cause of the failure: the problem is that 
Ranger opens the exact port as configured, but the code expects it to be on 
different IP address: per mini_ranger_kms.cc line 392, the expected URL is 
evaluated as Substitute("$0:$1/kms/v1/keys", host_, port_), where the 'port_' 
value comes from the lsof's output, but the 'host_' comes from 
GetBindIpForExternalServer(0), and it's different from the IP address that is 
used to bind the API's port.

For example, Ranger binds to 127.0.0.1:38663, but 'host_' is set to 
127.216.248.212.

Below is a snippet from the log:

I20231011 13:22:04.410434 1795043 test_util.cc:504] ITERATION 30:
p1797199
f174
n127.0.0.1:33516->127.216.248.212:38639
f175
n127.0.0.1:45640->127.216.248.212:59543
f177
n127.0.0.1:38663
I20231011 13:22:04.410535 1795043 mini_ranger_kms.cc:280] Ranger KMS bound to 
38663
I20231011 13:22:04.410547 1795043 mini_ranger_kms.cc:281] Ranger KMS URL: 
http://127.216.248.212:50959
I20231011 13:22:04.410580 1795043 mini_ranger_kms.cc:207] Time spent starting 
Ranger KMS: real 10.704s  user 0.055s     sys 0.144s
I20231011 13:22:04.410621 1795043 mini_ranger_kms.cc:389] 
{"name":"kuduclusterkey","cipher":"AES/CTR/NoPadding","length":128,"description":"kuduclusterkey"}
I20231011 13:22:04.410660 1795043 mini_ranger_kms.cc:393] 
127.216.248.212:38663/kms/v1/keys
E20231011 13:22:04.410877 1795043 mini_ranger_kms.cc:398]
/root/Projects/kudu/src/kudu/integration-tests/security-itest.cc:982: Failure
Failed
Bad status: Network error: Failed to create cluster key: curl error: Couldn't 
connect to server: Failed to connect to 127.216.248.212 port 38663: Connection 
refused


http://gerrit.cloudera.org:8080/#/c/20514/2//COMMIT_MSG@25
PS2, Line 25: If for some
            :   reason an other port is opened
> I think it makes sense to clarify what's the reason of that strange behavio
OK, per my analysis it's not true: the process doesn't open some other port, it 
opens exactly the port it's configured with (at least that's so in my 
environment).  The problem is that the API port binds to a different IP 
address, not the IP that the code expects.  And that what needs to be fixed, I 
guess.

See my comment on https://gerrit.cloudera.org/#/c/20514/2//COMMIT_MSG@10 for 
more details.



--
To view, visit http://gerrit.cloudera.org:8080/20514
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I89c3409e9efd53a821a6d4244a35564e134323bb
Gerrit-Change-Number: 20514
Gerrit-PatchSet: 2
Gerrit-Owner: Zoltan Martonka <[email protected]>
Gerrit-Reviewer: Alexey Serbin <[email protected]>
Gerrit-Reviewer: Kudu Jenkins (120)
Gerrit-Reviewer: Zoltan Martonka <[email protected]>
Gerrit-Comment-Date: Wed, 11 Oct 2023 20:57:19 +0000
Gerrit-HasComments: Yes

Reply via email to