bunch of stuff changing

If you're silly and merge migrations (or anything that prereleasers handle) at the same time as invalid yamls (or otherwise a failed deploy), prerelease will run but the deploy will not.

this kills the rails app

todo: wtf how does heroku get around this

Removal of certain resources should be possible, and driven by .tuber contents.

• Does everything need to log to sderr?
• Log Levels
• Always use zap, stop using the builtin logger
• Use context?

kubectl port-forward -n someapp `kubectl get pods -n someapp -o jsonpath="{.items[0].metadata.name}"` 8080:8080

ill have none of that

Right now, an end user can control anything about their namespace through .tuber's. Custom resources, extra resources, whatever. Except for secrets and configmaps.

Secrets and configmaps and their data shouldn't be committed to code, but we should be able to tear down and recreate a tuberapp entirely from 1 - the resources tuber creates, and 2 - the resources in .tuber.

How do we do this? Not sure.

Outstanding issues (that we know of):

• response from container registry does not contain Docker-Content-Digest header

• Add better error handling and logging around that ^
• Add Sentry env vars to cluster
• Add new subscription for staging tuber
• Add env var for subscription name in both staging and eng-internal

mostly the 404 on pulling the latest image - it tells you it 404'd, but it's unclear that the actual issue is that the build cant be found

• Create tuber-apps kubernetes secret
• Read credentials.json file into tuber-secrets

Maybe Terraform?

• Grant service account permissions from the given cluster to the freshly-docker project
  • Pub/Sub Subscriber
  • Container Registry Reader

Some ideas for naming
tuber install <cluster-name>
tuber configure <cluster-name>
tuber setup <cluster-name>

blocked by deploying as a part of install

any command that alters anything on the cluster should have a confirmation.
any command that reads data and does not alter anything should not require confirmation.

print context name to STDERR.

Tuberize an app

• Create .tuber directory in project root
• Create deployment.yaml
• Create service.yaml

🎉 jordan got his way

this would open the door to apps install resulting in a deployed app. or otherwise, using deploy like ever.

creds are used only for gcr, k8s rolebindings would still be in play

Tentative plan:
Add exec.yaml, a blank pod with no command - then

1. Exec applies it, but interpolates in a randomized name
2. Waits for success
3. Once successful, kubectl exec's with whatever command you passed in

except that won't work, WIP

Primarily removing a single tuber-app

This has changed quite a bit, now that we know what we're doing with istio.

I think this is now "add cluster setup" commands - such that once you have a fresh cluster, tuber can istio-ify.

Is that best done through giving tuber access to istio-system, and tuberizing the tuber-farm? Or.. what else?

On errors during setup, created resources should be deleted
create definitely

all commands should be idempotent. Should start with an audit

• Add (adds app to the tuber-apps config map, doesn't do anything else)
• Remove
• Create
• List

for reasons

It's a goroutine already, we might as well add a wait for the success of a release.

If the new pods enter crashloop, or otherwise don't run successfully, we should know about it.

Hopefully we can query on the revision, not on created pods, though.

Is there any other configuration that an app would need to read/write to besides env vars? If not, we can drop the env argument in the below command suggestions.

tubectl config set env NAME=VALUE
tubectl config get env NAME
tubectl config list env

Debating on the fact that people even need to know that configs are stored as Kubernetes secrets as opposed to plain config maps. It seems reasonable to group all of these commands under the name config.

Require a cluster or context flag to specify which cluster to operate on. It's similar to Heroku's -a --app flag.

Poor mans version of this is to add a confirm step before running any commands that modify the state of the cluster

Add encrypt and decrypt justfile definitions.

Something like this:

encrypt:
	cd {{ invocation_directory() }}; ../bin/encrypt credentials.json

decrypt:
	cd {{ invocation_directory() }}; ../bin/decrypt credentials.json.enc

currently panics because we suck