Cyrill commented on PR #6339: URL: https://github.com/apache/ozone/pull/6339#issuecomment-2006401676
VaultS3SecretStore still throws an exception if the configuration is incorrect. But the auth step is optional in the constructor. If the vault is up and running, the call succeeds. If not - the exception is logged and we proceed. Any further call to VaultS3SecretStore will anyway try to reauthenticate if it receives an 'auth failed' error, so the auth call in the constructor is more an optimization than a mandatory step. As for the transaction value apply order, I don't think I understand how a thirdparty service with its own lifecycle can be safely integrated into the current DB transactional flow without changing the flow itself. A call to storeSecret may fail, we cannot rely on the vault being 100% available. And the user should be notified that their secrets are not ready due to the vault issues, rather than crashing OM later while executing the transactional batch. With all that in mind, I don't think making a liveness check instead of storing secrets will help us. Imagine the liveness check succeeds, the S3GetSecretRequest finishes successfully, and a moment later the vault crashes. Then we flush the batch and the call to the vault fails. -- 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]
