>> 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) > > "integration of varlink in TripleO deployed containers" sounds like we'd > need to make some changes to the containers themselves, but is that the > case? As i read the docs, it seems like a management API wrapper for > Podman, so just an alternative interface to Podman CLI. I'd expect we'd > use varlink from Paunch, but probably not from the containers > themselves? (Perhaps that's what you meant, just making sure we're on > the same page.)
In fact, the "podman varlink thing" is already distributed with the podman package. In order to activate that socket, we just need to activate a systemd unit that will create the socket - the "service" itself is activated only when the socket is accessed. The only thing we might need to add as a package is the libvarlink-util (provides the "varlink" command) and the python3 binding (python3-libvarlink iirc). Varlink "activation" itself doesn't affect the containers. And yep, it's just an alternative to `podman' CLI, providing a nicer computer interface with python3 bindings in order to avoid "subprocess.Popen" and the like, providing a nice JSON output (well. mostly - I detected at least one output not properly formatted). > >> >> # a way to manage containers from within specific containers (think >> "healthcheck", "monitoring") by mounting the socket as a shared volume > > I think healthchecks are currently quite Docker-specific, so we could > have a Podman-specific alternative here. We should be careful about how > much container runtime specificity we introduce and keep though, and > we'll probably have to amend our tools (e.g. pre-upgrade validations > [2]) to work with both, at least until we decide whether to really make > a full transition to Podman or not. Of course - I just listed the possibilities activating varlink would provide - proper PoCs and tests are to be done ;). > >> >> # 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) >> >> 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 like it, but we should probably sync up with Podman community if they > consider varlink a "supported" interface for controlling Podman, and > it's not just an experiment which will vanish. To me it certainly looks > like a much better programmable interface than composing CLI calls and > parsing their output, but we should make sure Podman folks think so too :) I think we can say "supported", since they provide the varlink socket and service directly in podman package. In addition, it was a request: https://trello.com/c/8RQ6ZF4A/565-8-add-podman-varlink-subcommand https://github.com/containers/libpod/pull/627 and it's pretty well followed regarding both issues and libpod API updates. I'll ping them in order to validate that feeling. > > Thanks for looking into this > > Jirka > > [2] https://review.openstack.org/#/c/582502/ > >> >> 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
