[Cloud-admin] Re: About making toolforge a platform

As we have been working on gathering and defining user stories for the Toolforge Build Service and Toolforge itself, I have been thinking about the next steps for both of them, and surroundings and I wanted to share them and have some discussion to try to give a bit more direction to our work in those areas. == Tl;Dr; Let's think without constraints on what we want toolforge to become. My opinion: * Move towards full Platform as a Service ** this means users only interface with our platform ** this might mean offering k8s as a service on top of CloudVPS if needed * Simple thin client * Simple thin UI (for people that can't/don't want to use the client) * API that supports both the above == Long description I think that this is somewhat a popular idea, but I would like to but I would like toolforge to be as easy to use as digitalocean and heroku, that is, a PaaS platform. This means: * No need for ssh * Very simple cli (from the user's computer) * Simple web UI (same capabilities as the cli, for anyone that can't install the cli) This also means: * No k8s as a service (discussed later) * Detaching the users from the underlying implementation I know that this might require lots of changes, and those are not easy, but let's focus on the features we want, not the design underneath yet. What I would like is to have some set of "components" that I can use and combine to create my tool: Storage: * Store structured data somewhere (db) * Store unstructured data somewhere (storage/file-like?/s3?) Compute: * Something that runs periodically (cron-like) * Something that runs once (one-off) * Something that runs continuously (daemon) Network: * Create a public entry point for a web service * Connect between my components So inspired by the digitalocean[1] and heroku[2] clis, the toolforge cli could just do: * toolforge run * toolforge run-once * toolforge run-every * toolforge db * toolforge storage * toolforge expose-port (--public|--local) Some side-commands could be: * toolforge tool -> to manage tools themselves, (create/add-maintainer/remove-maintainer/...) * toolforge get-all -> to list all my components * toolforge logs -> get the logs for a component * toolforge shell -> start a shell inside a component container (similar to heroku bash), for debugging * toolforge edit-config -> to allow to do the above trough some kind of structured spec This is not an exhaustive list, but this should cover most of the usecases. You might be asking now, what about people that needs some extra features from k8s? For those, we can offer k8s as a service (through CloudVPS + terraform for example), so they have full control of their k8s instances. Note that I have tried to refrain myself from adding any implementation details yet, as I think that we should do the exercise of thinking what we want without limiting ourselves on how we think it could be done. The limitations will come later :) == Some random stats for current k8s toolforge usage Total number of namespaces: 3163 Of which, namespaces that are empty: 1496 That means that only 1667 have something, for those, number of k8s webservices: 1276 Number of grid webservices: 307 Number of tools with cronjobs: 71 Number of tools with >1 cronjob 47 Number of tools with >10 cronjob 6 Number of tools with manually defined resources: 51 Of which I checked a few, and could be sorted out with "continuous jobs", as in daemons, though I have not reviewed all of them in detail. [1] https://docs.digitalocean.com/reference/doctl/reference/apps [2] https://devcenter.heroku.com/categories/command-line