Add ctlog shards that create their own Cloud SQL instances.

[vaikas]

Signed-off-by: Ville Aikas vaikas@chainguard.dev

Summary

WIP: Need to do some testing, but wanted to share the approach early :)

Starts putting the pieces at the infra level necessary for:

• https://github.com/sigstore/public-good-instance/issues/343
• https://github.com/sigstore/public-good-instance/issues/418
• https://github.com/sigstore/public-good-instance/issues/524

In particular:

• Add mysql creation (optionally) into the CTLog module. It's made optional since we already use that module, and we don't
  want to create a new Cloud SQL instance for the already existing one.
• Add ctlog_shards variable to Sigstore ctlog_shards which is a list of shards. So we'd add, say 2021 into this list first to create a new separate Cloud SQL instance for the new CTLog
• Add ctlog_mysql_instances which outputs the list of CTLog DB instances

Release Note

• Add ability to create new CTLog shards with their own Cloud SQL instance.

Documentation

[vaikas]

Thank you so much @k4leung4
What's the best way to test these? Just run it against my own GKE project? Or are there other tests I could do?

[vaikas]

Tests are failures because v0.4.8 didn't roll out correctly. @cpanato and I have been trying to sort it.

[k4leung4]

Thank you so much @k4leung4 What's the best way to test these? Just run it against my own GKE project? Or are there other tests I could do?

yes, the best way to test/develop is to run it against your own project.
thats what most of us do.

[vaikas]

I've now tested (and fixed bunch of things that terraform plan showed). terraform plan now works with these 'garbage values':

terraform plan -var ctlog_shards="[2021, 2022]" -var project_id=vaikas -var attestation_bucket=a -var dns_domain_name=a -var dns_zone_name=a -var github_repo=f -var region=us-west1 -var tuf_bucket=a -var tuf_preprod_bucket=a -var tunnel_accessor_sa=a -out /tmp/plan

and it produces a bunch of stuff. I guess my next step here is to create the sigstore stack in my project without ctlog_shards defined, and then run it again with the ctlog_shards for the new 2021 and we should be seeing just a new DB being created.

I'll do that tomorrow.

[var-sdk]

Can we wire in a separate version (and tier) for ctlog? Trillian appears to have some performance problems with 8.0 and we will likely stick with 5.7 for prod so testing that in staging would be great. The tier is higher in staging because of the performance issues as well.

[var-sdk]

Context is https://github.com/sigstore/public-good-instance/issues/708.

[vaikas]

@var-sdk care to take one more look. Things got cleaned a bunch and now when applied with a new shard here:
https://github.com/sigstore/public-good-instance/pull/900

Only 3 resources were created:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:
<snip>
ctlog_mysql_connections = [
  "projectsigstore-staging:us-central1:sigstore-staging-ctlog-2022",
]
ctlog_mysql_instances = [
  "sigstore-staging-ctlog-2022",
]

And connected to the new DB and verified there was trillian database on that instance, but it was empty (no tables), which createdb will handle. Onto the helm charts :)

Thank you @k4leung4 for all the help here!!! ❤️