errose28 commented on PR #10991:
URL: https://github.com/apache/ozone/pull/10991#issuecomment-5496190901
## Default Write Pipeline Version Within the Datanode
There is the problematic case with using `STREAM_BLOCK_SUPPORT` as the
default minimum write pipeline version in the Datanodes which occurs when a
pre-finalized cluster is moving from a pre to post ZDU version, meaning we have
not switched to the unified version framework yet:
- Cluster is pre-finalized to an old layout version before `ZDU` i.e. it was
upgraded from an old version
- In the new upgraded software which is running, a newer version exists with
versioning on the write path
- Now an old pre-ZDU client arrives and does not forward a pipeline version
- The new feature using versioning in the write path will use `isAllowed` to
compare `STREAM_BLOCK_SUPPORT` (server default write pipeline component
version) to an old `layoutFeature`, which is not supported.
- If `STREAM_BLOCK_SUPPORT` happens to serialize to something less than
the old `layoutFeature` which is our current apparent version, we will
incorrectly allow the new write pipeline feature.
Instead, `ZDU` should be enforced as the lowest possible default value for
write pipeline version within the Datanode. If a client passes an unknown
version or any version less than `ZDU`, Datanodes should execute the write at
the `ZDU` version.
- Since the write pipeline version is derived from
`DatanodeDetails#currentVersion` (which may be an old component version) and
checked on the DN server (which may be on an old layout feature), it must
always be a type which can serve as both version types.
- ZDU is the first version that satisfies this.
- We know that there will be no pipeline versioning features until after
ZDU, so this is a safe lower bound on the DN
- New clients may still be given `STREAM_BLOCK_SUPPORT` as the current
version of the Datanode if HDDS is pre-finalized for `ZDU`. Since `ZDU` is the
first valid version to use in write pipeline versioning, Datanodes will round
this up to `ZDU` so there will not be an issue.
## Version Forwarding by the Client
Currently the `DatanodeDetails` object will automatically deserialize the
`currentVersion` field when it comes off the wire. We then re-serialize this
value to the `writePipelineVersion` sent back to the Datanodes. If the client
is older than the Datanode, this may cause `UNKNOWN_VERSION / -1` to be sent to
the the Datanodes as the write pipeline version. The write pipeline version
affects internal Datanode write semantics (like container schema version), so
the client being older should have no bearing on this. Instead,
`DatanodeDetails` needs to track the original `int` version that came with it
off the wire. `DatanodeDetails#getCurrentVersion` should still return the
serialized version, but we also need
`DatanodeDetails#getSerializedCurrentVersion` to return the original `int`
value to forward to Datanodes, which would be called by
`Pipeline#getWriteVersion`.
We can add a unit test for this in `TestContainerProtocolCalls` by creating
a `DatanodeDetails` object from a protobuf with current version
`Integer.MAX_VALUE` and checking that this value is preserved as the pipeline
write version in the request protobuf that is produced.
--
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]
