Please use varlink resolver, for the API examples

[afbjorklund]

Is this a BUG REPORT or FEATURE REQUEST?:

kind feature

Description

Currently all examples are hardcoding the socket location, such as:

$ varlink call -m unix:/run/podman/io.podman/io.podman.Ping
{
  "ping": {
    "message": "OK"
  }
}

This looks ugly (well, "verbose") and doesn't work over the ssh bridge...

• https://varlink.org/#bridge

It would be better if they would use the varlink resolver, to look like:

varlink call -m io.podman.Ping

---

It uses a hardcoded /run address, to resolve all other varlink services:

# varlink resolve io.podman
unix:/run/podman/io.podman;mode=0600

This does require that the org.varlink.resolver service has been set up.

• https://varlink.org/#resolver

Which requires that the resolver is responding, and configured properly.

# file /run/org.varlink.resolver 
/run/org.varlink.resolver: socket

[rhatdan]

@TomSweeneyRedHat Can you throw something together for this.

[rhatdan]

@baude Is the work you are doing with bridging helping here?

[rhatdan]

@baude is the work you are doing with bridging fixing this?

Is varlink resolver smart enough to do this? How would it find the socket?

[rhatdan]

@haraldh Do you have any ideas?

[afbjorklund]

I don't see how the examples are supposed to work over the bridge (by using the local socket)

Of course you could give an explicit --bridge and then hardcode the "other side", but anyway...
With the current system, the socket location takes precedence over the bridge - and makes it fail.

$ varlink --bridge "$VARLINK_BRIDGE" call -m unix:/run/podman/io.podman/io.podman.GetVersion
Unable to connect: CannotConnect

i.e. instead of using the SSH bridge command, it goes straight for a local /run/podman/io.podman

[afbjorklund]

Even better would be if one could avoid the bridge parameter: varlink/libvarlink#10

That would make the above command shorter:

$ varlink call io.podman.GetVersion
{
  "built": "2019-04-01T17:08:58Z",
  "git_commit": "ad467ba16e5f78a159c730ea005830cfa075de15-dirty",
  "go_version": "go1.12",
  "os_arch": "linux/amd64",
  "remote_api_version": 1,
  "version": "1.3.0-dev"
}

Or if using the go version of varlink instead:

$ varlink-go call io.podman.GetVersion
{
  "built": "2019-04-01T17:08:58Z",
  "git_commit": "ad467ba16e5f78a159c730ea005830cfa075de15-dirty",
  "go_version": "go1.12",
  "os_arch": "linux/amd64",
  "remote_api_version": 1,
  "version": "1.3.0-dev"
}

[haraldh]

Nobody should have to use varlink, the CLI command, manually in a terminal. It's only for debugging and bridging. varlink the API should be used by tools internally and not exposed to the CLI user.
So, examples should be given in golang or python or rust or C.

[afbjorklund]

The examples were on the API documentation page. Everyone elses uses pypodman or podman-remote

[haraldh]

Then the examples should be fixed in the podman API documentation

[afbjorklund]

So, something like this ?

$ python3 -m varlink.cli -b "$VARLINK_BRIDGE" call io.podman.GetVersion "{}"

Either way, it would still be better to use the resolver than to hard-code the socket.

And unfortunately, it is still an awful experience trying to install Python 3 on Windows...

[haraldh]

So, something like this ?

$ python3 -m varlink.cli -b "$VARLINK_BRIDGE" call io.podman.GetVersion "{}"

Either way, it would still be better to use the resolver than to hard-code the socket.

And unfortunately, it is still an awful experience trying to install Python 3 on Windows...

What? Shell again? Why?

[afbjorklund]

Same format as on https://github.com/varlink/python, feel free to write better examples.

The only point here was that it is wasteful to always say unix:/run/podman/io.podman

[afbjorklund]

Probably not going to bother with using varlink, might as well use commands directly over ssh instead.

That also means two less daemons to run (varlink resolver and podman varlink), and can use sudo...