HDDS-15184. Atomic Create-If-Absent Should Use 0 for Generation Match

[peterxcli]

What changes were proposed in this pull request?

We currently use an expected data generation of -1 to represent “create if absent”. In contrast, GCS uses -if-generation-match=0 for its create-if-absent semantics.

https://docs.cloud.google.com/storage/docs/xml-api/reference-headers#xgoogifgenerationmatch
If you set the x-goog-if-generation-match header to 0, Cloud Storage only performs the specified request if the object does not currently exist. For example, you can perform a PUT request to create a new object with a x-goog-if-generation-match, and the object will only get created if it doesn't already exist as a live version. If the object exists, the request is aborted.

One potential concern is whether the first object we create in Ozone could have a generation/update ID of 0, which would conflict with this encoding. In practice, this does not happen: committed keys in Ozone derive their updateID from the Ratis transaction index at commit time. The very first Ratis index (0) is reserved for startup/configuration log state before any client writes, so actual OM write requests always receive positive indices. As a result, committed keys will never have updateID == 0, and using 0 to encode “absent” is safe.

relate to: #9332

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15184

How was this patch tested?

existing test

[ivandika3]

LGTM +1. From the Raft paper, the first log index is 1 even without accounting for the startup log entry.

Edit: After looking again, Ratis log index starts from 0. However, as you said, the start up log entry should use that. So I think it's OK.

[peterxcli]

Thanks @ivandika3 for the review and the info!