While reading the news about dkr swarm and seeing what's going on at CoreOS' fleet, a mail to the ML from 2013 came into my mind.
There was someone asking for some network API for systemd, if I remember correctly. I think the answer was no, because you don't want systemd to be exposed to the "outer" world. I'm not keen to expose systemd to the network work either. But looking at fleet there seems to be some need to start/stop services/machines from remote. I asked myself if it does make sense to expose a subset of systemd's functionality to the network by introducing a small daemon - e.g. systemd-remoted - to the systemd ecosystem. I can image, that the daemon could expose: * Starting/Stopping of services * Starting/Stopping of VMs/containers * Pulling machines using machinectl pull-* * Maybe even something about the load of node where the daemon is running. The daemon could use some kind of rpc like REST+JSON or even the new kid on the block "google's grpc" (https://github.com/grpc/grpc, HTTP2, with bindings for c, c++, ruby, python, go, ...) to expose the API. I would see this daemon more as ground layer for some other cluster daemon which makes use of systemd-remoteds api. Does this make sense to you or is this totally non-sense and should better be solved elsewhere? Cheers /pp _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel