[
https://issues.apache.org/jira/browse/HDDS-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129123#comment-18129123
]
Andy Huang commented on HDDS-17140:
-----------------------------------
Yes, that is exactly what I meant—the first caller after cache expiry would
refresh the value synchronously.
Before proceeding, I would also like to get your thoughts on an alternative:
adding an optional apparent OM version field to each OMResponse. The client
could update its cached version when it observes a newer version, without
recreating the OzoneClient. This would let active clients discover finalization
on their next response, without background polling or a separate service-info
RPC.
One limitation is that some feature checks reject operations locally before
issuing an RPC. For those cases, we could retain an on-demand refresh after
cache expiry so the client can discover newly available features.
Would this approach be worth pursuing, or would you prefer keeping this change
focused on the 10-minute on-demand refresh?
> S3 Gateway does not pick up the new OM version after ZDU finalization
> ----------------------------------------------------------------------
>
> Key: HDDS-17140
> URL: https://issues.apache.org/jira/browse/HDDS-17140
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Chung-En Lee
> Assignee: Andy Huang
> Priority: Major
>
> The ZDU design doc ("Order of Operations During the Upgrade", step 5) says to
> rolling-restart S3 Gateway and other client processes on the new software
> before the cluster is finalized. At that point OM is still pre-finalized, so
> it reports the old version to clients.
> S3 Gateway learns the OM version only once, when it handles its first request
> after starting, and keeps it for the life of the process. In a ZDU rolling
> restart S3 Gateway keeps serving traffic, so it captures the old version
> before finalization. After the admin finalizes the cluster, OM reports the
> new version, but S3 Gateway keeps the old one. Any new feature that depends
> on the finalized OM version stays disabled in S3 Gateway until it is
> restarted again.
> Proposed fix (options):
> 1. Change the documented upgrade order so S3 Gateway is restarted after
> finalization.
> 2. Keep the current order, and document that S3 Gateway must be restarted
> again after finalization.
> 3. Make S3 Gateway aware OM version changes (e.g. after finalization) and
> re-initialize its OzoneClient automatically, so it picks up the latest OM
> version without a manual restart.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
