Create a LogReader without an appender

[haydentherapper]

Description

For a read-only server, e.g. one that's been frozen, that also serves read traffic for /checkpoint and /tiles, a personality needs the LogReader's ReadTile, ReadEntryBundle, and ReadCheckpoint functions. To create a LogReader, you must call tessera.NewAppender, which will also start a background thread to update the checkpoint, which is not desirable if the server is read-only.

Would it be possible to add a function to create a LogReader without an appender? IntegratedSize, NextIndex, and StreamEntries would not be needed, so not sure if it'd be preferable to create an interface that's a subset of LogReader that omits these, like FrozenLogReader. If not, do you have any suggested workarounds?

[haydentherapper]

I nerd-sniped myself into seeing what this might look like: main...haydentherapper:trillian-tessera:log-reader

[AlCutter]

Hi @haydentherapper, thanks for the request!

In general we strongly recommend that, if at all possible, you don't serve read traffic via your own frontends, and just let clients fetch these resources directly.

This is for a few reasons:

1. You'll be able to completely turn down the "moving parts" at the point that a log is frozen, and let the serving of the static parts continue to be someone else's problem. Saving you money as well as the operational burden of running them.
2. You'll end up "paying twice" for each request - once for reading from the underlying storage, but also in increased capacity for running frontend binaries (more CPU/RAM hours, VM instance time, more metric storage, possibly additional "egress", etc.)
3. For object storage in Cloud in particular, they can likely scale far larger, faster, and for lower cost than you can.

In effect, you'll be negating/giving up some of the benefits which come from Tessera's approach.

I understand that there may be reasons why that doesn't work for a particular use-case, though. In such a case I think it'd be really useful to dig into it and understand the underlying cause; there might be patterns which emerge over time which could feed into updates, functionality, design guidance, etc.

If this situation, one approach could be to do something like the POSIX conformance binary does, and proxy (or perhaps redirect with 301 Moved Permanently) incoming requests for paths which map to C2SP specified resources directly to the storage itself.

For a bit of broader context, we're trying hard to keep API surface as small and tight as possible so there's "just one way" to do things. Creating a "static resource only reader" lifecycle method is entirely possible (as you've shown!), but currently the only storage driver which actively requires something like that is the odd-one-out MySQL driver. I think we'd want to be sure that forcing all drivers to honour a new lifecycle function is the right call.

Could the proxy approach work for you in meantime while we chew on it?

[mhutchinson]

There's some brief documentation on freezing a log in the main README which summarizes what Al said: https://github.com/transparency-dev/trillian-tessera/?tab=readme-ov-file#freezing-a-log