Allow services to be deployed with specified cpu and memory requests
https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/
https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/
and/or enforce limits for all services
https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/

Variable limits should probably be accompanied by scaled pricing to both deploy and serve requests.

https://book.kubebuilder.io/cronjob-tutorial/cert-manager.html

we could use k3s/traefik built in let's encrypt, but then those become required codius dependencies...

crd should include hash of private variables but not the variables themselves
private variables must not be accessible to any other codius services

https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

https://book.kubebuilder.io/reference/writing-tests.html

Until now, users created Codius services by using their web monetization id as a bearer token (diagram). The codius host kubernetes cluster was configured to call an authentication token webhook (codius-auth) which would verify payment and return a user authorized to create Codius services.

GKE (and likely other cloud providers) do not allow you to configure an authentication token webhook.

Possible solutions include:

1. POSTing (or PUTing) services to the Codius host's /services API instead of the Kubernetes API Server. The bearer token can be checked for payment and the service created via the kubernetes client.
   If we go this route, users could even just use the classic Codius manifest instead of the Codius service custom resource. The fact that kubernetes is running underneath can be abstracted away.

2. Alternatively, we can double down on Kubernetes and follow this model:
   https://banzaicloud.com/blog/k8s-rbac/#what-about-cloud-provider-managed-kubernetes
   Users would query an authentication server with their web monetization id. (In the future, this could also include other identifying info for anti-spam purposes.) The auth server would:

   • verify payment
   • create a namespace for the user
   • create a role authorizing the default service account for the namespace to create and read Codius services
   • return the service account token

The user could then deploy a service using kubectl the same way they currently do:
kubectl create -f codius-service.yaml -s https://test.suidoc.net/ --token={token}
A Kubernetes controller would watch for new Codius services. When a new service is created in the namespace, the controller would attempt to verify payment for a subsequent service. If the balance is insufficient, the role would be updated to no longer allow service creation.
By charging per created service (as opposed to the current authentication token webhook charging per request), it should be possible for a Codius host to give users access to the kubernetes dashboard using their token.
One side effect of namespaced services is that unless the namespace was incorporated into the subdomain, a service could be deployed but not be available at service-name.codius-host-domain if another service with the same name had already been deployed to another namespace. The uploader could determine this in the services status from the services API.

tl;dr (1) "just" Codius vs (2) Codius as paid Kubernetes multitenancy

Codius services are currently immutable.
When a service is deployed, it is accessible at service-name.codius-host-domain. The service spec is available at codius-host-domain/services/service-name.
Previous versions of Codius used the spec hash as the subdomain instead of the service name.

With immutable services, these "vanity" subdomains are single use.

The following solution would make services mutable while making immutable versions accessible. It is similar to the concepts used in Knative:

In addition to Codius services, revisions would be added as a custom resource. A service would include a revision spec. The codius operator would automatically create a revision for each new service. It would also create deployments and k8s services from the revisions instead of the Codius services. Each revision would be accessible at revision-hash.codius-host-domain. The revision currently described in the codius service would also be accessible at service-name.codius-host-domain. The specific revision being served at the service subdomain can be found at codius-host-domain/services/service-name. (A key distinction from Knative is that every revision would be accessible, not just the current/specified one(s).) A revision could potentially be allowed to be deleted within ~1 hour of creation.

This would allow what's running at the service subdomain to be updated, while also offering immutable revisions at the hash subdomains.

This would require codius operator to be able to tie uploader identity (currently web monetization id, a more robust anti spam method in the future) to a service, in order to authorize only the original service uploader to be able to update that service. Both solutions described in #16 would achieve this. (For solution #2, the uploader would have full CRUD capability for services within their assigned namespace. Namespaced services would also mean a service would not be available at the subdomain if the name already existed in a different namespace, but the revision would still be available at the hash subdomain.)

Don't allow names used for codius host infrastructure:

• deploy
• auth
• acme
• ...

Should this be enforced by the crd itself?