On 08/17/2018 12:25 AM, Steve Baker wrote: > > > On 15/08/18 21:32, Cédric Jeanneret wrote: >> Dear Community, >> >> As you may know, a move toward Podman as replacement of Docker is starting. >> >> One of the issues with podman is the lack of daemon, precisely the lack >> of a socket allowing to send commands and get a "computer formatted >> output" (like JSON or YAML or...). >> >> In order to work that out, Podman has added support for varlink¹, using >> the "socket activation" feature in Systemd. >> >> On my side, I would like to push forward the integration of varlink in >> TripleO deployed containers, especially since it will allow the following: >> # proper interface with Paunch (via python link) > I'm not sure this would be desirable. If we're going to all container > management via a socket I think we'd be better supported by using CRI-O. > One of the advantages I see of podman is being able to manage services > with systemd again.
Using the socket wouldn't prevent a "per service" systemd unit. Varlink would just provide another way to manage the containers. It's NOT like the docker daemon - it will not manage the containers on startup for example. It's just an API endpoint, without any "automated powers". See it as an interesting complement to the CLI, allowing to access containers data easily with a computer-oriented language like python3. >> # a way to manage containers from within specific containers (think >> "healthcheck", "monitoring") by mounting the socket as a shared volume >> >> # a way to get container statistics (think "metrics") >> >> # a way, if needed, to get an ansible module being able to talk to >> podman (JSON is always better than plain text) >> >> # a way to secure the accesses to Podman management (we have to define >> how varlink talks to Podman, maybe providing dedicated socket with >> dedicated rights so that we can have dedicated users for specific tasks) > Some of these cases might prove to be useful, but I do wonder if just > making podman calls would be just as simple without the complexity of > having another host-level service to manage. We can still do podman > operations inside containers by bind-mounting in the container state. I wouldn't mount the container state as-is for mainly security reasons. I'd rather get the varlink abstraction rather than the plain `podman' CLI - in addition, it is far, far easier for applications to get a proper JSON instead of some random plain text - even if `podman' seems to get a "--format" option. I really dislike calling "subprocess" things when there is a nice API interface - maybe that's just me ;). In addition, apparently the state is managed by some sqlite DB - concurrent accesses to that DB isn't really a good idea, we really don't want a corruption, do we? > >> That said, I have some questions: >> ° Does any of you have some experience with varlink and podman interface? >> ° What do you think about that integration wish? >> ° Does any of you have concern with this possible addition? > I do worry a bit that it is advocating for a solution before we really > understand the problems. The biggest unknown for me is what we do about > healthchecks. Maybe varlink is part of the solution here, or maybe its a > systemd timer which executes the healthcheck and restarts the service > when required. Maybe. My main concern is: would it be interesting to compare both solutions? The Healthchecks are clearly docker-specific, no interface exists atm in the libpod for that. So we have to mimic it in the best way. Maybe the healthchecks place is in systemd, and varlink would be used only for external monitoring and metrics. That would also be a nice way to explore. I would not focus on only one of the possibilities I've listed. There are probably even more possibilities I didn't see - once we get a proper socket, anything is possible, the good and the bad ;). >> Thank you for your feedback and ideas. >> >> Have a great day (or evening, or whatever suits the time you're reading >> this ;))! >> >> C. >> >> >> ¹ https://www.projectatomic.io/blog/2018/05/podman-varlink/ >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cédric Jeanneret Software Engineer DFG:DF
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
