ivandika3 commented on PR #7988:
URL: https://github.com/apache/ozone/pull/7988#issuecomment-2809189534
After discussion with @xichen01 , we identified an issue of using `omNodeId`
in the OM request might have issues where the client and server configurations
have different OM node IDs.
For example, OM server configuration
```
<property>
<name>ozone.om.service.ids</name>
<value>service1</value>
</property>
<property>
<name>ozone.om.address.service1.om1</name>
<value>10.0.0.1</value>
</property>
<property>
<name>ozone.om.address.service1.om2</name>
<value>10.0.0.2</value>
</property>
<property>
<name>ozone.om.address.service1.om3</name>
<value>10.0.0.3</value>
</property>
```
OM client configuration
```
<property>
<name>ozone.om.service.ids</name>
<value>service1</value>
</property>
<property>
<name>ozone.om.address.service1.om4</name>
<value>10.0.0.1</value>
</property>
<property>
<name>ozone.om.address.service1.om5</name>
<value>10.0.0.2</value>
</property>
<property>
<name>ozone.om.address.service1.om6</name>
<value>10.0.0.3</value>
</property>
```
The client request will always be rejected since the client OM node ID is
always different than the leader.
One possible solution is to have a simple flag to allow read from non-leader
instead of omNodeId. If the flag is set, then read from non-leader is allowed,
if flag is not set, then read from non-leader is disallowed. We can remove the
OM node ID mismatch logic entirely.
Please let me know what 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: issues-unsubscr...@ozone.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org
For additional commands, e-mail: issues-h...@ozone.apache.org
