Update loginfo API endpoint to return information about inactive shards#738
Update loginfo API endpoint to return information about inactive shards#738dlorenc merged 3 commits intosigstore:mainfrom
Conversation
priyawadhwa
force-pushed
the
loginfo-treeid
branch
from
963bbcc to
94efbc5
Compare
Codecov Report
@@ Coverage Diff @@
## main #738 +/- ##
==========================================
- Coverage 47.48% 47.21% -0.27%
==========================================
Files 66 66
Lines 5716 5742 +26
==========================================
- Hits 2714 2711 -3
- Misses 2713 2741 +28
- Partials 289 290 +1
Continue to review full report at Codecov.
|
This also updates `rekor-cli` to verify inactive shards if they exist. It also updates the sharding integration test to run loginfo and store state based on TreeID if available. Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
priyawadhwa
force-pushed
the
loginfo-treeid
branch
from
94efbc5 to
e8d9d0e
Compare
dlorenc
left a comment
dlorenc
left a comment
There was a problem hiding this comment.
One tiny not, otherwise LGTM!
Signed-off-by: Priya Wadhwa <priya@chainguard.dev>
lkatalin
left a comment
lkatalin
left a comment
There was a problem hiding this comment.
Awesome!
I had a couple of informational questions that would help me understand some of the code.
| // sign the log root ourselves to get the log root signature | ||
| if _, err := sth.Sign(viper.GetString("rekor_server.hostname"), api.signer, options.WithContext(ctx)); err != nil { | ||
| return nil, err | ||
| } |
There was a problem hiding this comment.
How does this get the log root signature?
There was a problem hiding this comment.
Ah okay, I think I get it, this enables us to get the signature later (not in this line of code) with sth.Signatures - the lack of clarity is just from me being less familiar here, I appreciate the explanation.
| log.CliLogger.Infof("Unable to store previous state: %v", err) | ||
| } | ||
| } | ||
| if err := state.Dump(serverURL, &sth); err != nil { |
There was a problem hiding this comment.
If there is no treeID this will just dump from the URL, but if there is both a treeID and a URL, what happens? Does the URL only cover the active tree and only in the case of an older client? Or does some state get stored twice?
There was a problem hiding this comment.
Some state will get stored twice! But when reading from the file the client will always prefer the treeID over the URL.
There was a problem hiding this comment.
Okay cool, yeah I see that in oldState. Just trying to understand the mechanism here - the URL covers all trees, right? What does dumping by treeID (if available) add?
There was a problem hiding this comment.
So if we have two shards, they'll be accessed at the same URL (e.g. rekor.sigstore.dev). We can't store state for both of them, because the key by URL would be the same. The TreeID is unique for each shard, so we can store state for all shards at once if we use treeID as the key.
There was a problem hiding this comment.
I think this makes sense, I see it is a hash map so we're giving it differentiated keys. I will try to get some output to see it for myself. Thanks for the explanation.
4 participants
I updated the
LogInfoobject in the openapi spec to also return information about inactive shards.This PR also updates
rekor-cli loginfoto verify inactive shards if they exist.loginfowill now first attempt to store state instate.jsonby TreeID instead of URL (that's because the URL for different shards is the same so this will prevent shards overwriting each other). If no TreeID is present then it will fall back to using the URL, so this change is backwards compatible.This PR also updates the sharding integration test to run loginfo on inactive shards to ensure this works as expected.
cc @lkatalin @bobcallaway
fixes #713
Signed-off-by: Priya Wadhwa priya@chainguard.dev