[openstack-dev] [TripleO] podman: varlink interface for nice API calls

Cédric Jeanneret cjeanner at redhat.com
Fri Aug 17 05:34:59 UTC 2018


>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180817/976051a4/attachment.sig>


More information about the OpenStack-dev mailing list