Add the ability to build a remote client in golang that uses all
the same front-end cli code and output code. The initial limitations
here are that it can only be a local client while the bridge and
resolver code is being written for the golang varlink client.
Tests and docs will be added in subsequent PRs.
Signed-off-by: baude <bbaude@redhat.com>
It was setting the wrong variable (CamelCase)
in the wrong module ("main", not "libpod")...
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
For the sake of debug and problem reporting, we would benefit from knowing
what buildah version was vendored into podman. Also, knowing the distribution
and distribution version would also be handy.
Signed-off-by: baude <bbaude@redhat.com>
when using the varlink api, we should pass on the registries information
as is present in the cli info command.
Signed-off-by: baude <bbaude@redhat.com>
Need to get some small changes into libpod to pull back into buildah
to complete buildah transition.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #1270
Approved by: mheon
Rather than making a runtime each time a client hits a varlink endpoint, we now
make a single runtime when the varlink service starts up. This fixes a problem
where we hit a max inotify limit from CNI.
Resolves: #1211
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1215
Approved by: rhatdan
The varlinfo info returns the same information as podman info but always includes
the so-called debug information.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #745
Approved by: baude
implement varlink image functions for working with libpod with the exception of a
couple due to incompletions on the libpod side of things (build).
also, created a first pass at a libpodpy package which will stand as a client to
working with libpod's varlink methods using python.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #669
Approved by: baude
baude
Anders F Björklund
Daniel J Walsh