support CLI plugins

[muayyad-alsadi]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description
as discussed here
it's good to have a podman <COMMAND> by running executable named podman-<COMMAND>
found in /usr/libexec/podman/cli-plugins/ or ~/.podman/cli-plugins

[rhatdan]

If you have plugins in both directories, we execute the local ones?

~/.config/containers/cli-plugins?
~/.local/share/containers/cli-plugins?

[muayyad-alsadi]

yes, I believe ~/.local/share/ should have priority over ~/.config/, user over global, and local over system-wide

in the spec
~/.config is like /etc for config
and ~/.local/share is like /usr/share for data files

the spec does not mention anything about libexec (never seen something like ~/.local/libexec/containers/cli-plugins before)

they have a colon separated XDG_DATA_DIRS that is to default to /usr/local/share/:/usr/share/

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

[rhatdan]

Ok I guess your suggested directories work, since this would be specific to Podman as well.

[vrothberg]

How should the API of such plugins look like?

[Luap99]

I think we should match the docker cli API. This would allow people to use docker cli plugins as well.

[Luap99]

Also see #5802

[vrothberg]

I think we should match the docker cli API. This would allow people to use docker cli plugins as well.

Is it documented somewhere?

[muayyad-alsadi]

here

docker/cli#1534

basically it's an executable that accepts argument docker-cli-plugin-metadata to print a json
otherwise it just shift the arguments

#! /bin/bash

# put this file in /usr/libexec/docker/cli-plugins/docker-demo

[ "x$1" == "xdocker-cli-plugin-metadata" ] && {
    echo '{
     "SchemaVersion": "0.1.0",
     "Vendor": "Muayyad Alsadi",
     "Version": "v0.0.1",
     "ShortDescription": "Demo docker command"
}'
exit 0
}

export
echo got params "$@"

[vrothberg]

Thanks!

I just briefly skimmed the plugins code and am not entirely convinced that's something Podman should support. The documentation/specification really is in the code which is completely outside of our control. I am mostly afraid of a potential whack-a-mole and the maintenance burden.

@muayyad-alsadi, can you elaborate on a use case? Podman supports OCI hooks which may meet your requirements already.

[Luap99]

See the old issue which has more context.
docker/docs#10852 says it is deprecated. However it seems that docker still uses for many tools, e.g. docker-compose v2.

OCI hooks are different than a generic cli plugin. Hooks can only be used for a container lifecycle. For a tool like compose you cannot use hooks, you want the user to type a specific command.

I never understand why someone would need a plugin in the first place, what is the problem with typing podman-foo or just foo vs podman foo.

[muayyad-alsadi]

says it is deprecated. However it seems that docker still uses for many tools, e.g. docker-compose v2.

yes, the old docker-compose was not a cli plugin, the new v2 is a cli plugin
so is scan plugin
so is buildx

https://github.com/docker/scan-cli-plugin/

can you elaborate on a use case?

podman-compose and maybe scan ...etc.

OCI hooks are different than a generic cli plugin. Hooks can only be used for a container lifecycle. For a tool like compose you cannot use hooks, you want the user to type a specific command.

exactly

I never understand why someone would need a plugin in the first place, what is the problem with typing podman-foo or just foo vs podman foo.

so users can find help in one place

# docker --help

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/root/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/root/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/root/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/root/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Management Commands:
  app*        Docker App (Docker Inc., v0.9.1-beta3)
  builder     Manage builds
  buildx*     Docker Buildx (Docker Inc., v0.7.1-docker)
  config      Manage Docker configs
  container   Manage containers
  context     Manage contexts
  demo*       Demo docker command (Muayyad Alsadi, v0.0.1) <----------------------- this is my above bash script
  image       Manage images
  manifest    Manage Docker image manifests and manifest lists
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  scan*       Docker Scan (Docker Inc., v0.12.0)
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

[vrothberg]

@containers/podman-maintainers PTAL

[mheon]

The question for me is, will the Docker Compose v2.x tool remain a CLI plugin?

If so, that's a pretty significant incentive for us to support the Docker plugin model, even if it is official deprecrated and mostly undocumented. With a few simple steps, a user can have Docker Compose, or Podman Compose, or both, directly integrated into the Podman CLI, and that's a very powerful argument.

Unfortunately, I don't really have an answer here. The Docker folks say they're looking into integrating compose v2.0 more directly, which would presumably not involve CLI plugins, but we don't know if that is going to happen or when.

[rhatdan]

If we could do this simply, IE if an executable is in a directory, then we can show it in the help, and execute the commands, then I am fine with it. If it involves huge engineering, then I agree it is not worth it.

[muayyad-alsadi]

if an executable is in a directory, then we can show it in the help, and execute the commands

This is exactly this is what I want. Just execute the binary and display help.

[rhatdan]

PRs welcome. :^)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[sebdanielsson]

/remove stale

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[sebdanielsson]

/remove

[ashley-cui]

@karthikelango137

[karthikelango137]

git it

[Luap99]

Before there is to much work done on this we should agree on a design first.

cc @containers/podman-maintainers

[vrothberg]

Before there is to much work done on this we should agree on a design first.

docker/cli#1534 should summarize the design quite well. Certainly, we need to support the Docker-specific paths and also look up plugins with s/docker/podman in the paths.

[rhatdan]

Right, I want to keep this as simple as possible at least to start. Goal would be to make podman compose work with docker-compose as MVP.

Getting podman FOOBAR to launch the FOOBAR executable and pass arguments to FOOBAR
podman --help to show FOOBAR is installed, for example.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@karthikelango137 Any progress or should I assign this to someone else?

[karthikelango137]

@karthikelango137 Any progress or should I assign this to someone else?

I plan to begin next week. Do you think 4-5 weeks is enough time for this? I want to do it, but don't want to hold the team back.

[rhatdan]

Start it and then we can follow up. See if you can get small chunks in and we can have people help you out.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@karthikelango137 did you make any progress?

[karthikelango137]

@karthikelango137 did you make any progress?

No, I haven't started it. Is this the route we are taking to support third party commands? I'm not sure if we confirmed this or not.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[cdoern]

@rhatdan would this be something good for me to do? or is it low priority

[rhatdan]

Sure as long as you keep it simple.

[Luap99]

@baude You were talking to me about this, WDYT?

[vrothberg]

I think we've discussed this idea in detail last year and concluded to not pursue it, so I am closing the issue as not planned. Please reopen or speak up if I am mistaken.