<rekado_>I think we’re not realizing the full potential of Guix as it comes to containers.
<rekado_>state of the art is to bundle things up, upload to a registry, transfer the archive from the registry to the server, mount the file system it contains in a container, and then launch the application
<rekado_>Guix enables ephemeral file systems — we don’t even need to bundle things up first
<rekado_>but this also means that we don’t have a convenient unit of describing containers for consumption by existing tools and services
<rekado_>if I wanted to use any sort of commercial platform that lets me launch containers I’m almost inevitably restricted to using Docker: registries and images.
<rekado_>e.g. Amazon’s ECS (container service) and ECR (container registry), but also any kubernetes platform.
<rekado_>these things exist primarily because it’s no longer acceptable to start a new server just because you want to run a new service, nor is it okay to manually add a new service to an existing server.
<rekado_>why not “acceptable”? Because there are situations where you want to automate this and treat all your servers (whether VMs or physical) as an amorphous “computing substate”.
<rekado_>this goes beyond cattle vs pets. This is cattle vs ground beef.
<rekado_>nodes and schedulers and tasks that are launched on any free node.
<rekado_>but also: tasks that are long lived and can be migrated to larger nodes.
<rekado_>so… what can we do with Guix in the realm of imageless container orchestration?
<efraim>I'm not entirely sure if you're looking at a "replacement" for dockerhub or something similar, currently I have a (system) user running shepherd who has some shell scripts which launch containers or environments
<efraim>ok, i'm reading it again and seeing you're looking for orchastration. would it need to run on top of Guix System?
<rekado_>it would not neet to run on top of Guix System.
<rekado_>it would however need to be able to make use of existing services
<drakonis>is this meant for giving guix a foothold into the cloud?
<drakonis>i'm currently working on a distributed daemon
<drakonis>but is this for providing containers generated by guix or something that runs a bit more higher up in the chain?
<drakonis>the build coordinator and cuirass as well
<drakonis>also i can't help but think that ditching the current store model would help with some other pains
<drakonis>the only thing that's stored on sqlite right now is the node graph
<rekado_>with GWL there are two reasons for keeping out of the daemon: 1) we don’t want to store huge input or output files in /gnu, which is both precious and inconvenient to work with; 2) we want to run workflows without *needing* an active Guix installation on the executing nodes. We just need (declared parts of) /gnu as a read-only file system slice.