google / trillian

A transparent, highly scalable and cryptographically verifiable data store.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Tombstone and remove current map server & storage code

AlCutter opened this issue · comments

The newer approach is already present in the experimental directory, and early examples of how to use it is in the experimental sumdb project in trillian-examples.

KT depends on Maps as currently implemented. We would need to pin it to the latest release.

Is KT in use? I think their repository is currently broken anyway?

I propose that we create a Trillian release in the next week or so that still includes the map in its current state. The next release of Trillian will cut the map out. This seems like a reasonable compromise so that anyone still wanting to play with the old map can pin to this release, and it prevents the release being blocked on PRs which are deleting the map (which I imagine will take a while to see through).

Also, maybe we can time this with "finalising" v1 branch, and setting foundation for v2:

  • Create a "permanent" v1 branch, with maps still in it. The last v1 release will be tagged on this v1 branch. (or reuse v1.3 that we have)
  • Commit to v1 only to fix issues and support prod (including our internal).
  • Start breaking things in master. Delete maps, minimise the rest of the code.
  • Whenever ready, create v2 branch/label/release from master.

Deleting maps to some non-breaking degree could still be done in v1.

I missed a detail previously: the KT repo (which I believe has been broken for other reasons for a good while) is pinning two Trillian versions behind.

So there's nothing we can do that will break KT any further, and this issue is essentially done?

Yeah, the KT aspect is no longer a factor/blocker here, I think.

The only remaining factor is that the last release was a few months ago, so we might want: a) fresh "final" map-inclusive release, b) declaring in release notes that Map is being removed in the next release(s). Even though the Map isn't part of the "supported" API, it spans half the API, so deleting it seems like a thing that's good to announce in some way. Do release notes seem like a right place?

If the "final" map-inclusive release is for the benefit of map users, my hypothesis is that there are none, and I would think that having it "one last time" can only encourage new potential users to appear (and soon be disappointed), even with an announcement?

The backing for my hypothesis is that the map API as it is at the moment is so incredibly difficult to use "correctly" that I would consider it broken, and code using it likely to be broken as well (so removing it breaks nothing new).

Marking this as fixed. Any remaining parts of the map should be fairly simple to remove as they are rediscovered. If that's not the case and I need to dive in further, then reopen this.