> Ex. ports: [ "80/http", "8080/http", ] > While a stylistic choice, it also makes it a PITA for others to write parsers for their DSL, and generally isn’t as r

> Ex. ports: [ "80/http", "8080/http", ] > While a stylistic choice, it also makes it a PITA for others to write parsers for their DSL, and generally isn’t as readable as say the vanilla Kubernetes port model. These are CLI shorthands. There is a canonical expanded-out object that you would use if you were scripting something or talking to the API. > Looking at the list above of what we need (or can) provide for a deployment, it doesn’t seem we are at any higher a level of abstraction than we are when just using Kubernetes. Of course the same basic concepts of what to run, where to store output and how to take input are needed to describe computing. But there's two ways to run things ("containers" stay running, "jobs" finish) instead of 8 to choose from (bare pod, deployment, replicationcontroller, replicaset, daemonset, statefulset, cronjob, job) with all slightly varying syntaxes. The args/volumes/secrets aren't just things that will be created, but also documentation and first-class objects that can be configured/overridden by the consumer of the Acorn. Without you adding dozens of lines of values.yaml and golang template soup to a helm chart to allow every possible configuration a user might want (and never quite the same way in two different helm charts from 2 different people). You can create an image with reasonable defaults to work for dev/toying around on a laptop; run a local database, generate the secret for it automatically, etc. With the tools needed to ship and run that same artifact in production but pointed at a real DB in RDS. Packaged up as one OCI image so there's one artifact to manage from one source, instead of a helm chart + n images from n containers from n registries. (Acorn cofounder)