First of all this removes the need for a network connection, second
renovate can update the version as it is tracked in go.mod.
However the real important part is that the binary downloads are
broken[1]. For some reason the swagger created with them does not
include all the type information for the examples. However when building
from source the same thing works fine.
[1] https://github.com/go-swagger/go-swagger/issues/2842
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Not sure why this only triggers now but this code was broken for a
while. It is racy as reported on the issue but because it changes the
actual map part of the network backend it means it can also alter the
behavior of the network which is very bad.
Fixes#22330
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I am really not sure why the caller even should have the option to set
this. We should always use the correct isolation type based on the
privileges the server runs under never the client. podman-remote build
seems to send the default based on its local privs which was wrong as
well. To fix this I also changed the client to send the default if the
isolation flag is not set.
Fixes#22109
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Also update the website to display the correct swagger doc for the right
version, the 5.0 swagger file will not exist until we branch but I added
it anyway so we do not forget it.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add a --artifact flag to `podman manifest add` which can be used to
create an artifact manifest for one or more files and attach it to a
manifest list. Corresponding --artifact-type, --artifact-config-type,
--artifact-config, --artifact-layer-type, --artifact-subject, and
--artifact-exclude-titles options can be used to fine-tune the fields in
the artifact manifest that don't refer to the files themselves.
Add a --index option to `podman manifest annotate` that will cause
values passed to the --annotation flag to be applied to the manifest
list as a whole instead of to an entry in the list.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Like docker podman network inspect should output the information of
running container with their ip/mac address on this network.
However the output format is not docker compatible as this cannot
include all the info we have and the previous output was already not
compatible so this is not new.
New example output:
```
[
{
...
"containers": {
"7c0d295779cee4a6db7adc07a99e635909413a390eeab9f951edbc4aac406bf1": {
"name": "c2",
"interfaces": {
"eth0": {
"subnets": [
{
"ipnet": "10.89.0.4/24",
"gateway": "10.89.0.1"
},
{
"ipnet": "fda3:b4da:da1e:7e9d::4/64",
"gateway": "fda3:b4da:da1e:7e9d::1"
}
],
"mac_address": "1a:bd:ca:ea:4b:3a"
}
}
},
"b17c6651ae6d9cc7d5825968e01d6b1e67f44460bb0c140bcc32bd9d436ac11d": {
"name": "c1",
"interfaces": {
"eth0": {
"subnets": [
{
"ipnet": "10.89.0.3/24",
"gateway": "10.89.0.1"
},
{
"ipnet": "fda3:b4da:da1e:7e9d::3/64",
"gateway": "fda3:b4da:da1e:7e9d::1"
}
],
"mac_address": "f6:50:e6:22:d9:55"
}
}
}
}
}
]
```
Fixes#14126
Fixes https://issues.redhat.com/browse/RHEL-3153
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Moving from Go module v4 to v5 prepares us for public releases.
Move done using gomove [1] as with the v3 and v4 moves.
[1] https://github.com/KSubedi/gomove
Signed-off-by: Matt Heon <mheon@redhat.com>
This mirrors how the Docker API handles things, allowing us to be
more compatible with Docker and more verbose on the Libpod API.
Stats are given as per network interface in the container, but
still aggregated for `podman stats` and `podman pod stats`
display (so the CLI does not change, only the Libpod and Compat
APIs).
Signed-off-by: Matt Heon <mheon@redhat.com>
The pasta network mode has been added in podman v4.4 and this causes a
conflict with named networks that could also be called "pasta". To not
break anything we had special logic to prefer the named network over the
network mode. Now with 5.0 we can break this and remove this awkward
special handling from the code.
Containers created with 4.X that use a named network pasta will also
continue to work fine, this chnage will only effect the creation of new
containers with a named network pasta and instead always used the
network mode pasta. We now also block the creation of networks with the
name "pasta".
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Podman Desktop [1] is looking into improving the user experience which
requires to know the source of an image. Consider the user triggers an
image pull and Podman Desktop wants to figure out whether the image name
refers to a Red Hat registry, for instance, to prompt installing the RH
auth extension.
Since the input values of images may be a short name [2], Podman Desktop
has no means to figure out the (potential) source of the image. Hence,
add a new `/resolve` endpoint to allow external callers to figure out
the (potential) fully-qualified image name of a given value.
With the new endpoint, Podman Desktop can ask Podman directly to resolve
the image name and then make an informed decision whether to prompt the
user to perform certain tasks or not. This for sure can also be used
for any other registry (e.g., Quay, Docker Hub).
[1] https://github.com/containers/podman-desktop/issues/5771
[2] https://www.redhat.com/sysadmin/container-image-short-names
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
When inspecting a container that does not define any health check, the health field should return nil. This matches docker behavior.
Signed-off-by: Ashley Cui <acui@redhat.com>
SpecGen is our primary container creation abstraction, and is
used to connect our CLI to the Libpod container creation backend.
Because container creation has a million options (I exaggerate
only slightly), the struct is composed of several other structs,
many of which are quite large.
The core problem is that SpecGen is also an API type - it's used
in remote Podman. There, we have a client and a server, and we
want to respect the server's containers.conf. But how do we tell
what parts of SpecGen were set by the client explicitly, and what
parts were not? If we're not using nullable values, an explicit
empty string and a value never being set are identical - and we
can't tell if it's safe to grab a default from the server's
containers.conf.
Fortunately, we only really need to do this for booleans. An
empty string is sufficient to tell us that a string was unset
(even if the user explicitly gave us an empty string for an
option, filling in a default from the config file is acceptable).
This makes things a lot simpler. My initial attempt at this
changed everything, including strings, and it was far larger and
more painful.
Also, begin the first steps of removing all uses of
containers.conf defaults from client-side. Two are gone entirely,
the rest are marked as remove-when-possible.
[NO NEW TESTS NEEDED] This is just a refactor.
Signed-off-by: Matt Heon <mheon@redhat.com>
Cut is a cleaner & more performant api relative to SplitN(_, _, 2) added in go 1.18
Previously applied this refactoring to buildah:
https://github.com/containers/buildah/pull/5239
Signed-off-by: Philip Dubé <philip@peerdb.io>
* Add BaseHostsFile to container configuration
* Do not copy /etc/hosts file from host when creating a container using Docker API
Signed-off-by: Gavin Lam <gavin.oss@tutamail.com>
The push binding endpoint wasn't actually writing the
output data to the stream when quiet=false and there
was no push error.
Do not hard code quiet=true anymore, take into account the
user input.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
When committing containers to create new images, accept a container
config blob being passed in the body of the API request by adding a
Config field to our API structures. Populate it from the body of
requests that we receive, and use its contents as the body of requests
that we make.
Make the libpod commit endpoint split changes values at newlines, just
like the compat endpoint does.
Pass both the config blob and the "changes" slice to buildah's Commit()
API, so that it can handle cases where they overlap or conflict.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Instead of relying on the remote server to create tar files
with the right account IDs (which the remote server doesn't
even know, when the client and server run under different accounts),
have the remote client ignore the account IDs when unpacking.
Then just hard-code 0 in the remote server, so that the remote
server's account identity does not leak in the tar file contents.
Compare https://github.com/containers/image/issues/1627 .
[NO NEW TESTS NEEDED] : https://github.com/containers/podman/pull/18563
suggests that existing tests already cover these code paths / properties.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Added additional check for event type to be remove and set the correct exitcode.
While it was getting difficult to maintain the omitempty notation for Event->ContainerExitCode, changing the type from int to int ptr gives us the ability to check for ContainerExitCode to be not nil and continue operations from there.
closes#19124
Signed-off-by: Chetan Giradkar <cgiradka@redhat.com>
Podman build --remote is translating https://path as if it was a file
path. This change will leave it as a URL so it can be parsed on the
server side.
Fixed: https://github.com/containers/podman/issues/20475
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The endpoints to (dis-)connect networks from/to a container are
no longer no-ops. Furthermore, the 403 error handled since #20365
has been documented
Signed-off-by: Philipp Fruck <dev@p-fruck.de>
commit fa19e1baa27024f8e0078e27254a8cfb6586f9f4 partially introduced
the fix, but was merged too quickly and didn't work with remote.
Introduce a new binding to allow removing a session from the remote
client.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When trying to connect a container to a network and the connection
already exists, an error should only be raised if the container is
already running (or is in the `ContainerStateCreated` transition)
to mimic the behavior of Docker as described here:
https://github.com/containers/podman/pull/15516#issuecomment-1229265942
For running and connected containers 403 is returned which fixes#20365
Signed-off-by: Philipp Fruck <dev@p-fruck.de>
Allow users to specify
podman-remote top $cid -eo "pid comm"
or
podman-remote top $cid -eo pid,comm
Fixes: https://github.com/containers/podman/issues/19176
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
didid# new file: test/system/085-top.bats
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Add a new `compatMode` parameter to libpod's pull endpoint. If set, the
streamed JSON payload is identical to the one of the Docker compat
endpoint and allows for a smooth integration into existing tooling such
as podman-py and Podman Desktop, some of which already have code for
rendering the compat progress data.
We may add a libpod-specific parameter in the future which will stream
differnt progress data.
Fixes: issues.redhat.com/browse/RUN-1936?
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Break out the code for pulling images via the compat API. The goal is to
make this code shareable between the compat and libpod API to allow for
a "compat mode" in the libpod pull endpoint.
[NO NEW TESTS NEEDED] as it should not change behavior.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The libpod containers create endpoint wasn't checking whether
the image existed before creating the container. If the image
doesn't exist, it should return a 404 status code but it was
failing and returning a 500 status code.
This fix matches the behavior of the compat endpoint.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
