Currently, orchestration/ contains serai-orchestrator, a Rust binary to output Containerfiles, the runtime/ subfolder (containing the canonical build process for serai-runtime and supplementary evidence), and some miscellaneous scripts.
I am fine with this, because I think it's functional and it works for the purposes of dev tooling, which is all I need from it. I have heard others may want more competent tooling that more properly integrates however.
One of the big issues re: the current Containerfile templating is how secrets are directly written into them (defining the service's private keys). We need to define on a proper secret store, remove secrets from the Containerfiles, and adjust serai-env accordingly.
The premise to template Containerfiles isn't fundamentally bad though, and we probably will always want a templating solution. Whether or not that's our own Rust binary can be discussed, but I don't mind the existence of serai-orchestrator in general.
I think the other issue will be regarding the active management of images, containers, and volumes. Presumably, once we have the Containerfiles, we would want to integrate with something like Kubernetes? The important thing is that system administrators are comfortable maintaining the actively running services and don't need to read a textbook on our bespoke oddities.
Currently,
orchestration/containsserai-orchestrator, a Rust binary to outputContainerfiles, theruntime/subfolder (containing the canonical build process forserai-runtimeand supplementary evidence), and some miscellaneous scripts.I am fine with this, because I think it's functional and it works for the purposes of dev tooling, which is all I need from it. I have heard others may want more competent tooling that more properly integrates however.
One of the big issues re: the current
Containerfiletemplating is how secrets are directly written into them (defining the service's private keys). We need to define on a proper secret store, remove secrets from theContainerfiles, and adjustserai-envaccordingly.The premise to template
Containerfiles isn't fundamentally bad though, and we probably will always want a templating solution. Whether or not that's our own Rust binary can be discussed, but I don't mind the existence ofserai-orchestratorin general.I think the other issue will be regarding the active management of images, containers, and volumes. Presumably, once we have the
Containerfiles, we would want to integrate with something like Kubernetes? The important thing is that system administrators are comfortable maintaining the actively running services and don't need to read a textbook on our bespoke oddities.