-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
content: track RFC 10 protocol changes #4299
Conversation
Problem: some content backing store tests refer to "rooref" when "rootref" was intended. This appears to have proliferated via cut and paste. Fix typos.
Problem: the size of the hash digest corresponding to a blobref is not disclosed to users of the blobref class. Have blobref_validate_hashtype() return the digest size on success, instead of zero. Update tests.
Problem: now that protocols use hash digests directly, it is inconvenient to have to convert a blobref from blobref_hash() back to a digest. Add blobref_hash_raw() which just computes the digest. Add unit tests.
Problem: libcontent internal functions are named inappropriately given RFC 10 protocol changes in the pipeline. We will still want functions that operate on blobrefs for convenience, but also more efficient ones that match the protocol. In anticipation of this, rename: content_load() -> content_load_byblobref() content_store_get() -> content_store_get_blobref() Update users.
2e594e7
to
1b5b7b2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looked through everything and didn't see anything other than just this 1 nit!
src/common/libcontent/content.c
Outdated
} | ||
|
||
int content_load_get (flux_future_t *f, const void **buf, int *len) | ||
{ | ||
return flux_rpc_get_raw (f, buf, len); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: errant extra line added?
Problem: the RFC 10 content protocol has been updated to use raw hash digests instead of blobrefs, but flux-core still uses blobrefs. Convert to the new protocol. This includes updating - libcontent - broker content cache - all the content backing modules In addition, use the first eight bytes (sizeof (size_t)) of the hash digest directly as the hash key in the content cache, which should already be evenly distributed over its range and more efficient than hash digest -> blobref -> Bernstein_hash (blobref) Update content backing module sharness tests which use the load/store protocol directly.
Problem: the althash s3 test fails because it reuses the bucket from the content-s3 test with an incompatible hash. Append the test name to the s3 bucket to avoid this. Also drop the second s3 test that uses sha1, since that was already covered in content-s3.
Problem: a generic test in the althash sharness test had the S3 prereq. Drop S3 prereq. The test is not S3 related.
1b5b7b2
to
36cc523
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had gone through this PR and did some local testing with no issues, but forgot to come back and approve. LGTM!
Thanks guys, setting MWP. |
This implements the protocol change proposed in flux-framework/rfc#330, in which blobref strings are replaced with the raw hash in content load/store RPCs. The broker content-cache also now uses hashes instead of blobrefs as the zhashx key.
The RPC wrappers in libcontent were updated, so their users including
flux-content
,flux-dump
,flux-restore
, and the KVS module did not really have to change, although some of the libcontent functions were renamed.One thing that superficially worked before but no longer works at all after this change is modifying the hash algorithm across an instance restart. If we want to enable a system instance to migrate from sha1 to sha256, a dump/restore will be required and the content back ends will need to treat an attempt to restart under a different hash as a fatal error. Since we don't yet have TOML support for changing the hash algorithm, I think we don't necessarily need to fix that here.