RFC: Supporting libpod REST API

[Elkasitu]

Context

Currently, all podman operations done by podman-compose are done by executing podman as a program and passing it various command-line arguments.

Podman offers a REST API exposed through unix sockets, I believe it's possible to use this API for most if not all podman operations currently used by podman-compose.

Rationale

I think using the API would result in many benefits, including but not limited to:

• Cleaner, more robust code
• Less boilerplate
• Potentially better performance
• Potentially easier to test
• Offloading of certain things (e.g. thread creation for podman start) to libpod

Notes

• At least on my machine, using the API requires either starting the socket as a user (e.g. systemctl --user start podman.socket) or running whatever program requires access to the socket as sudo. There's probably a way to config with udev rules so that a non-root user can use the socket, this should be documented if the rest API support is green lit.
• This would require a transition period, meaning for a while both command-line and rest api commands would be supported, IMO the best way to do this would be to initially test if the unix socket is available and use that by default, otherwise fallback to command-line calls. This behavior could be overridden by a flag (maybe).

Are there any reasons not to use the REST API exposed by libpod? (other than it consuming a lot of time? :^))

Any comments, questions, etc. welcome

[muayyad-alsadi]

I have answered this many times

Please post it here

https://github.com/containers/podman-compose/discussions

And read the readme.

[Elkasitu]

I tried searching for any issues mentioning this but had no luck.

As for the README, I have read it but I don't see anything that explains why not use the API, I guess you meant the part about "losing the process-model" but that doesn't really explain why.

Will create the discussion sometimes tonight, thanks.

[muayyad-alsadi]

#456