Priya Wadhwa

As far as I know, Option 1 is the plan! (each shard uses the same signer).

Yah I think the main goal was to shard on some cadence (~ once/year) so the log doesn't get too big (but I've only been looking at this feature for...

Update: I was wrong! We'll need one signer/shard.

The [tests](https://github.com/sigstore/rekor/blob/main/tests/e2e_test.go) have pretty good coverage for uploading different types of objects (rekor, intoto attestation, jar etc), but it seems like they won't run against prod until it's updated to...

Everything I mentioned in https://github.com/sigstore/rekor/issues/841#issuecomment-1142405342 is covered now by probers or tests. The harness tests also test adding/retrieiving entries across the most recent three server/CLI versions. Personally I think this...

> Could the issue with trillian trees not necessarily being chronologically ordered be fixed by Rekor code ordering them and keeping track? We can order trees chronologically during runtime, there's...

> but now realizing that steps 1-4 are manual and 5 is implemented in code - is this right? Yep! I think that removing the tree length requirement is the...

Update: With https://github.com/sigstore/rekor/pull/810 we've pretty much removed downtime, instead there is a small race condition when the Rekor deployment is spinning down old pods (which point to the old shard)...

> Regarding the proposal around seamless updates, is it rollback safe? That's a good point. If we're automatically marking logs as FROZEN when they're in the sharding config, we would...

Re: my initial idea around marking pods as FROZEN; I think an easier way of achieving the same thing would be to mark the Rekor deployment strategy as [Recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment) --...