Remove CNI-specific conditional logic and update comments throughout
the libpod networking code:
- Simplified DNS configuration logic in container_internal_common.go
to always use netavark behavior (removed backend checks)
- Removed CNI-specific iptables chain error regex pattern
- Updated all comments referencing 'CNI' to use 'netavark' or
'network backend'
- Renamed variable 'cniNet' to 'netInfo' for clarity
- Updated field and type documentation to remove CNI references
All networking code now assumes netavark as the sole backend.
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Remove user-facing CLI options for CNI network backend:
CLI flags:
- Keep --network-backend global flag as hidden and deprecated for
backward compatibility with cleanup commands from 5.x containers
- Map flag to a throwaway variable (value is ignored)
- Remove shell completion for network backend values
Shell completions:
- Remove AutocompleteNetworkBackend() function
- Remove references to CNI and Netavark type constants
Backward compatibility:
- Remove --rootless-cni flag alias for podman unshare
- Remove SetNormalizeFunc that mapped rootless-cni to rootless-netns
- Update --rootless-netns flag description to mention only netavark
The --network-backend flag remains as a hidden deprecated flag to
prevent failures when upgrading from 5.x where containers may have
cleanup commands that include this flag. The flag is accepted but
ignored. Users can no longer specify CNI as a network backend option.
The --rootless-cni alias is removed; users must use --rootless-netns.
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
This also then bumps github.com/opencontainers/runtime-spec to v1.3.0
which contains breaking changes of the pid type as such we had to update
all the podman callers.
And tags.cncf.io/container-device-interface also used some changed
types from it and they have been updated in main so bump to the latest
commit there as well in order to get podman to compile properly.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This also includes a number of significant changes to the SQLite
state made possible by removal of the legacy DB.
1. Enable database unit tests for SQLite state, with numerous
tweaks to get tests passing. Most notable changes are to
container removal - where we previously didn't return an error
if there was no container to remove - and RemovePodContainers,
which I don't think ever worked properly from my reading of
the failures.
2. Removal of AddContainerToPod/RemoveContainerToPod. On SQLite,
these functions are identical to AddContainer/RemoveContainer
and there is no reason to retain duplicates.
3. Removal of SafeRewriteContainerConfig - it's identical to
RewriteContainerConfig in SQLite, no reason to have duplicate
entrypoints.
As an exciting side-note, this removes Podman's requirement that
containers and pods cannot share a name, which was a BoltDB
restriction only.
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Tremendous amount of changes in here, but all should amount to
the same thing: changing Go import paths from v5 to v6.
Also bumped go.mod to github.com/containers/podman/v6 and updated
version to v6.0.0-dev.
Signed-off-by: Matt Heon <mheon@redhat.com>
Using golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize
+ some manual cleanup in libpod/lock/shm/shm_lock_test.go as it
generated an unused variable
+ restored one removed comment
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
unconfined is a special value and not a path as such it must not be
converted otherwise --security-opt seccomp=unconfined fails as it tries
to access a file called unconfined.
Fixes: 3e8b2d7d96 ("Fix seccomp profile path on Windows")
Fixes: #26855
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Added log_path variable in containers/common, User sets default log path in containers.conf under the `[containers]` section.
The directory has to exist beforehand. Container logs go under this directory, sub-directories named with the container id
and inside the sub-directory a ctr.log file will be created where the container logs for the corresponding container will go.
This path can be overridden by using the `--log-opt` flag.
Signed-off-by: Joshua Arrevillaga <2004jarrevillaga@gmail.com>
An artifact without the title annoation just gets the digest as name
which is less than ideal. While it is a decent default to avoid
conflicts users would like to configure the name.
With the name=abc option we will call the file abc in case of a signle
artifact and otherwise we use abc-x where x is the layer index starting
at 0 to avoid conflicts.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Given I wrote this and I still mess it up on a regular basis, I
cannot be alone in forgetting whether "dst" or "dest" is the
correct short option for "destination". Let's just make both
valid, I don't see a reason not to.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The Windows source folder path was not converted in the corresponding
machine folder path when the volume was of type overlay as it does for
other bind mount volumes.
Fix#25988
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
This commit adds two new annotations named
io.podman.annotations.cpuset/$ctrname and
io.podman.annotations.memory-nodes/$ctrname
The first one allows restricting a container's execution to specific
CPU cores while the second restricts memory allocations to specific
NUMA memory nodes. They are also added automatically when the
--cpuset-cpus and --cpuset-mems options are used.
Fixes: containers#26172
Signed-off-by: François Poirotte <clicky@erebot.net>
When podman restarts config values within the Engine are lost.
Add --hook-dirs arguments as appropriate to the cleanup command
so that hooks are preserved on restarts due to the on-restart setting
Tests: add a check that prestart/poststop hooks ran every time after 2
restarts.
`wait_for_restart_count` was re-used to wait for restarts and moved to
helpers file.
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Fixes: #17935
This fixes an issue where multiple paths separated by a colon were
treated as a single path, contrary to what docs say and unlike how mask
option works.
Test was updated with a case that fails without this commit.
Signed-off-by: Šimon Škoda <ver4a@uncontrol.me>
This commit adds new annotation called:
io.podman.annotations.pids-limit/$ctrname
This annotation is used to define the PIDsLimit for
a particular pod. It is also automatically defined
when newly added --pids-limit option is used.
Fixes: #24418
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Add a new option to allow for mounting artifacts in the container, the
syntax is added to the existing --mount option:
type=artifact,src=$artifactName,dest=/path[,digest=x][,title=x]
This works very similar to image mounts. The name is passed down into
the container config and then on each start we lookup the artifact and
the figure out which blobs to mount. There is no protaction against a
user removing the artifact while still being used in a container. When
the container is running the bind mounted files will stay there (as the
kernel keeps the mounts active even if the bind source was deleted).
On the next start it will fail to start as if it does not find the
artifact. The good thing is that this technically allows someone to
update the artifact with the new file by creating a new artifact with
the same name.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Use a helper struct to hold the mounts instead of returning 5+ return
values from the functions. This allows use to easily add more volume
types without having to update all return lines every time in the
future. And 5+ return values are really not readable anymore so this
should make it easier to follow the code.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This should be set only by podman as it is used for the podman generate
systemd --new command. For the api it was set to the system service
command which is simply pointless. It must be empty in these cases.
Fixes#25026
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Fixes: https://github.com/containers/podman/issues/25002
Also add the ability to inspect containers for
UseImageHosts and UseImageHostname.
Finally fixed some bugs in handling of --no-hosts for Pods,
which I descovered.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
* Add --hosts-file flag to container create, container run and pod create
* Add HostsFile field to pod inspect and container inspect results
* Test BaseHostsFile config in containers.conf
Signed-off-by: Gavin Lam <gavin.oss@tutamail.com>
New flags in a `podman update` can change the configuration of HealthCheck when the container is started, without having to restart or recreate the container.
This can help determine why a given container suddenly started failing HealthCheck without interfering with the services it provides. For example, reconfigure HealthCheck to keep logs longer than the usual last X results, store logs to other destinations, etc.
Fixes: https://issues.redhat.com/browse/RHEL-60561
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
All the backend work was done a while back for image volumes, so
this is effectively just plumbing the option in for volumes in
the parser logic. We do need to change the return type of the
volume parser as it only worked on spec.Mount before (which does
not have subpath support, so we'd have to pass it as an option
and parse it again) but that is cleaner than the alternative.
Fixes#20661
Signed-off-by: Matt Heon <mheon@redhat.com>
Similar to github.com/containers/buildah/pull/5761 but not
security critical as Podman does not have an expectation that
mounts are scoped (the ability to write a --mount option is
already the ability to mount arbitrary content into the container
so sneaking arbitrary options into the mount doesn't have
security implications). Still, bad practice to let users inject
anything into the mount command line so let's not do that.
Signed-off-by: Matt Heon <mheon@redhat.com>
These flags can affect the output of the HealtCheck log. Currently, when a container is configured with HealthCheck, the output from the HealthCheck command is only logged to the container status file, which is accessible via `podman inspect`.
It is also limited to the last five executions and the first 500 characters per execution.
This makes debugging past problems very difficult, since the only information available about the failure of the HealthCheck command is the generic `healthcheck service failed` record.
- The `--health-log-destination` flag sets the destination of the HealthCheck log.
- `none`: (default behavior) `HealthCheckResults` are stored in overlay containers. (For example: `$runroot/healthcheck.log`)
- `directory`: creates a log file named `<container-ID>-healthcheck.log` with JSON `HealthCheckResults` in the specified directory.
- `events_logger`: The log will be written with logging mechanism set by events_loggeri. It also saves the log to a default directory, for performance on a system with a large number of logs.
- The `--health-max-log-count` flag sets the maximum number of attempts in the HealthCheck log file.
- A value of `0` indicates an infinite number of attempts in the log file.
- The default value is `5` attempts in the log file.
- The `--health-max-log-size` flag sets the maximum length of the log stored.
- A value of `0` indicates an infinite log length.
- The default value is `500` log characters.
Add --health-max-log-count flag
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Add --health-max-log-size flag
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
Add --health-log-destination flag
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
The podman container cleanup process runs asynchronous and by the time
it gets the lock it is possible another podman process already did the
cleanup and then did a new init() to start it again. If the cleanup
process gets the lock there it will cause very weird things.
This can be observed in the remote start API as CI flakes.
Fixes#23754
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This started off as an attempt to make `podman stop` on a
container started with `--rm` actually remove the container,
instead of just cleaning it up and waiting for the cleanup
process to finish the removal.
In the process, I realized that `podman run --rmi` was rather
broken. It was only done as part of the Podman CLI, not the
cleanup process (meaning it only worked with attached containers)
and the way it was wired meant that I was fairly confident that
it wouldn't work if I did a `podman stop` on an attached
container run with `--rmi`. I rewired it to use the same
mechanism that `podman run --rm` uses, so it should be a lot more
durable now, and I also wired it into `podman inspect` so you can
tell that a container will remove its image.
Tests have been added for the changes to `podman run --rmi`. No
tests for `stop` on a `run --rm` container as that would be racy.
Fixes#22852
Fixes RHEL-39513
Signed-off-by: Matt Heon <mheon@redhat.com>
The pod was set after we checked the namespace and the namespace code
only checked the --pod flag but didn't consider --pod-id-file option.
As such fix the check to first set the pod option on the spec then use
that for the namespace. Also make sure we always use an empty default
otherwise it would be impossible in the backend to know if a user
requested a specific userns or not, i.e. even in case of a set
PODMAN_USERNS env a container should still get the userns from the pod
and not use the var in this case. Therefore unset it from the default
cli value.
There are more issues here around --pod-id-file and cli validation that
does not consider the option as conflicting with --userns like --pod
does but I decided to fix the bug at hand and don't try to fix the
entire mess which most likely would take days.
Fixes#22931
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Image volumes (the `--mount type=image,...` kind, not the
`podman volume create --driver image ...` kind - it's strange
that we have two) are needed for our automount scheme, but the
request is that we mount only specific subpaths from the image
into the container. To do that, we need image volume subpath
support. Not that difficult code-wise, mostly just plumbing.
Also, add support to the CLI; not strictly necessary, but it
doesn't hurt anything and will make testing easier.
Signed-off-by: Matt Heon <mheon@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>
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>
