Alexey Serbin has posted comments on this change. Change subject: [system_catalog] an option to reset CA entries in system table ......................................................................
Patch Set 1: > This is a little funny as a flag, since if you're running > multi-master, and you start with this, you'll end up with a new CA, > and then on first fail-over, the second master will also create a > new CA. > Right. This looks like a hack and really it is :) This is the patch that I put up yesterday to quickly fix an issue JD had on his cluster. > A couple ideas: > > 1) an offline tool would be "safer" as a one-shot? though if it's a > lot of work to build, probably not worth it I think an additional off-line tool is much better, of course. > 2) what if we added a log line on "LoadCertificateAuthority" which > output some kind of unique ID for the loaded cert? And then the > flag could be --remove_cert_id=<cert>. That would make it safe to > leave the flag set, since on failover the new master would see that > the cert had already been deleted? That might be a better approach as well. However, it requires to know what certificates you have there. And stand-alone tool could be much better anyway. -- To view, visit http://gerrit.cloudera.org:8080/6135 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9c9cdab5f6a2887304f60705d2945d1462c369bc Gerrit-PatchSet: 1 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Alexey Serbin <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Dan Burkert <[email protected]> Gerrit-Reviewer: Jean-Daniel Cryans <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Todd Lipcon <[email protected]> Gerrit-HasComments: No
