errose28 commented on PR #3395:
URL: https://github.com/apache/ozone/pull/3395#issuecomment-1121560396
We discussed this offline, but an important difference between bucket layout
validation and layout feature validation is that once a layout feature is
finalized, it can never be un-finalized. This means if we let a request through
the validator based on a layout feature, we know that information is still
valid in validateAndUpdateCache. This is not necessarily the case for bucket
layouts. After the validator checks the bucket by its name, a bucket can be
deleted and recreated with the same name and a different layout before the
request is passed on to validateAndUpdateCache. There are a few ways we can
handle this, some of which we discussed previously:
1. Recheck the same validator condition in validateAndUpdateCache of every
relevant request.
- This could become error prone if new validators are added, as it
requires an identical update in two places for correctness.
2. Check that the bucket ID we checked against in the validator matches the
same bucket ID we get in validateAndUpdateCache.
- Since bucket layout is currently immutable for a given bucket, this
should give us correct results.
- One way to do this could be to add a field to the `OmBucketInfo` for
"validated bucket ID", and then in some part of the serialized Ratis write path
add a check that "validated bucket ID" matches the actual bucket ID if it is
present.
- For new requests, they would only need to modify code in the validator.
- This general approach could help with the non-FSO/FSO request splitting
problem as well, where we must check the bucket layout outside the serialized
path to determine whether to send an FSO or non-FSO request, but must validate
that when the request is applied that is still the bucket's correct layout.
3. Refactor the validators to allow them to be triggered in a serialized
part of the Ratis apply transaction path.
- This might require more work. We have numerous improvements to the
validators in mind already, so maybe this can be added as a todo if it is not
feasible right now.
- This will not help the non-FSO/FSO request splitting problem mentioned
above.
2 seems like the best option to me, but others please add your thoughts as
well.
--
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]
