HDDS-14957. Separate OpenKeyInfo to differentiate KeyInfo#10181
HDDS-14957. Separate OpenKeyInfo to differentiate KeyInfo#10181YutaLin wants to merge 5 commits intoapache:masterfrom
Conversation
|
Hi @peterxcli, @ivandika3 |
peterxcli
left a comment
peterxcli
left a comment
There was a problem hiding this comment.
Thanks @YutaLin for this patch. Code overall looks good, could you help me to see if we could introduce new class om open key info and repeated om key info with minimal copying overheard? As I think that would be much cleaner. Appreciate!
|
Hi @peterxcli, thanks for review! |
| if (isOpenKey) { | ||
| if (expectedDataGeneration != null) { | ||
| kb.setExpectedDataGeneration(expectedDataGeneration); | ||
| } | ||
| if (expectedETag != null) { | ||
| kb.setExpectedETag(expectedETag); | ||
| } |
There was a problem hiding this comment.
My ultimate goal is to remove this, like just make the OmKeyInfo do not accept these field as member, and that's why I purpose we have to have a named Codec class with the OmKeyInfo proto msg for each scenario(eg. key table, open key table, file table)
There was a problem hiding this comment.
definitely can just merge current change, and leave this as followup for more reasoning.
2 participants
What changes were proposed in this pull request?
Introduce new codec for OmKeyInfo to filter fields only for OpenKeyTable
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-14957
How was this patch tested?
CI Actions(https://github.com/YutaLin/ozone/actions/runs/25272906337)