Implement APIs for read server #270
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #270 +/- ##
==========================================
+ Coverage 39.11% 39.73% +0.62%
==========================================
Files 39 40 +1
Lines 2751 2831 +80
==========================================
+ Hits 1076 1125 +49
- Misses 1571 1600 +29
- Partials 104 106 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This allows for deployers to serve read traffic without a separate CDN/proxy. This is discouraged for GCP, since it's more costly to serve read traffic in terms of egress costs, but can be used for other backends and for local testing. Signed-off-by: Hayden B <[email protected]>
haydentherapper
force-pushed
the
read-server
branch
from
59078fc to
dcdfa09
Compare
cmurphy
left a comment
cmurphy
left a comment
There was a problem hiding this comment.
This is discouraged for GCP
I think we would never want to use this for GCP. Instead of adding a --serve-read-paths flag, could this just be directly tied to the backend in use?
| rekorServer := server.NewServer(tesseraStorage, readOnly, algorithmRegistry) | ||
| var rekorServer server.RekorServer | ||
| if viper.GetBool("serve-read-paths") { | ||
| rekorServer = server.NewReadServer(tesseraStorage, readOnly, algorithmRegistry) |
There was a problem hiding this comment.
Need to fix - This breaks with --read-only because tesseraStorage is nil but is still needed on the read path.
There was a problem hiding this comment.
transparency-dev/tessera#625 to see if Tessera can add a function that would give us a LogReader without an appender
For POSIX, it depends. I'd imagine a common deployment would be to serve the read path via nginx or some other load balancer that serves the /tiles directory. If a deployer wouldn't want to stand up an additional load balancer and doesn't expect significant read traffic, just the server should be able to handle both read and write traffic (pending load tests to verify this). Technically, if someone didn't want to deal with managing a load balancer or public buckets, they could serve read traffic for GCP from the service. I wouldn't be opposed to only allowing a subset of supported backends to serve read traffic though. |
2 participants
This allows for deployers to serve read traffic without a separate
CDN/proxy. This is discouraged for GCP, since it's more costly to serve
read traffic in terms of egress costs, but can be used for other
backends and for local testing.
Rebased on #269.
Summary
Release Note
Documentation