Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/11956 )
Change subject: [sentry] add mini Sentry to the external mini cluster ...................................................................... Patch Set 9: (4 comments) http://gerrit.cloudera.org:8080/#/c/11956/2/src/kudu/mini-cluster/external_mini_cluster.cc File src/kudu/mini-cluster/external_mini_cluster.cc: http://gerrit.cloudera.org:8080/#/c/11956/2/src/kudu/mini-cluster/external_mini_cluster.cc@257 PS2, Line 257: hms_->EnableKerberos(kdc_->GetEnvVars()["KRB5_CONFIG"], spn, ktpath, > Hmm, it looks like so. Although all of our work are based Hive 2.3.x curren Yeah, and looks like Hive 4 isn't even released yet. Making our own fork of Hive 2.3.x to apply this one patch is probably too much work, so I guess we'll have to live with this. When you merge, could you file a Kudu JIRA to track the progression of this Hive feature, so that when we do upgrade to a version of Hive that supports it, we'll be able to simplify this code? http://gerrit.cloudera.org:8080/#/c/11956/9/src/kudu/mini-cluster/external_mini_cluster.cc File src/kudu/mini-cluster/external_mini_cluster.cc: http://gerrit.cloudera.org:8080/#/c/11956/9/src/kudu/mini-cluster/external_mini_cluster.cc@269 PS9, Line 269: // Restart Sentry with the HMS address. Even though we can't configure HMS's bind address, I think we can still avoid a restart: 1. Generate a UNIQUE_LOOPBACK address for Sentry. 2. Statically choose a non-zero port that Sentry will use. Since Sentry will live on its own UNIQUE_LOOPBACK, there's no danger of collision with anything else and you could pick whatever port number you wanted. 3. Start HMS configured to talk to Sentry at the address you got in #1 and port you got in #2. 4. Start Sentry configured at the address/port from #1/#2, and configured to talk to the HMS from #3. Granted, this only works well for UNIQUE_LOOPBACK, so macOS will need to do the restart thing. Would the code get too messy with a UNIQUE_LOOPBACK case and a non-UNIQUE_LOOPBACK case? FWIW I'd have a pretty high tolerance for messy code in this case because the payoff is so significant (faster test run time on Linux). http://gerrit.cloudera.org:8080/#/c/11956/9/src/kudu/sentry/mini_sentry.h File src/kudu/sentry/mini_sentry.h: http://gerrit.cloudera.org:8080/#/c/11956/9/src/kudu/sentry/mini_sentry.h@99 PS9, Line 99: std::string ip_{"0.0.0.0"}; Now I'm confused; why did you switch from copy init to value init? Copy init is more familiar to most people. http://gerrit.cloudera.org:8080/#/c/11956/8/src/kudu/tools/tool.proto File src/kudu/tools/tool.proto: http://gerrit.cloudera.org:8080/#/c/11956/8/src/kudu/tools/tool.proto@65 PS8, Line 65: // Whether or not the Sentry service should be set up. > Would you mind I do this in a follow up patch? This reminds me to add a tes Sure, please revert this hunk then. -- To view, visit http://gerrit.cloudera.org:8080/11956 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I7f02e6085bd239570d10ec629f48856d37ed6e59 Gerrit-Change-Number: 11956 Gerrit-PatchSet: 9 Gerrit-Owner: Hao Hao <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Hao Hao <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Tidy Bot (241) Gerrit-Comment-Date: Thu, 13 Dec 2018 00:03:23 +0000 Gerrit-HasComments: Yes
