fapifta commented on code in PR #5404:
URL: https://github.com/apache/ozone/pull/5404#discussion_r1374568921
##########
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OzoneManager.java:
##########
@@ -647,6 +647,11 @@ private OzoneManager(OzoneConfiguration conf,
StartupOption startupOption)
omStorage, omInfo, "",
scmInfo == null ? null : scmInfo.getScmId(),
this::saveNewCertId, this::terminateOM);
+ if (recoverCertificate) {
+ certClient.initWithRecovery();
Review Comment:
I am not sure if we really need this code here... Let me share my thought
process on this.
Previously, we did not call init() on the CertificateClient here. This is
happening during normal startup, and so far the expectation during normal
startup was that data is present.
So if there was a failure, an OM start with --init was able to solve the
problems for which we had an automatic resolution. So here we are changing the
semantics, and basically that seems to be the cause of the failure during
TestOzoneManagerListVolumeSecure.
Now with this change, we introduce a new flag to circumvent the test
problem, and introducing a change in OM startup semantics. I am wondering if we
should do it, what are the advantages? Note that init is designed to be
idempotent, so it is safe to run before any regular startup to ensure the state.
Currently if there is a problem with the certificates, a regular startup
fails, with that notifying operators that there is something to check into
here, and the fix requires intervention. With this change we hide problems with
security material, as it is automatically fixed at regular startup, I am not
sure if it is desirable, is it?
In the currently handled case it might be desirable, as only public
information is missing (with that possible tinkered with), but introducing
other fixes where private material is also affected, that might change the
landscape.
What do you think?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
