Add an `--ignore` flag to `podman image rm` to instruct ignoring image
if a specified image does not exist and to not throw an error. Other
commands (e.g., `podman container rm`) already support this flag.
Such an `--ignore` flag can come in handy in clean-up scripcts such as
the teardown phases in the Podman tests.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The example is also improved to add the --subnet option, this option is required with netavark, else you get:
Error: macvlan driver needs at least one subnet specified, DHCP is not supported with netavark
Signed-off-by: Clayton Craft <clayton@craftyguy.net>
Allow users to add annotions in the podman play kube command.
This PR Also fixes the fact that annotations in the pod spec were
not being passed down to containers.
Fixes: https://github.com/containers/podman/issues/12968
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If you want to remove a running machine, you can now pass the --force/-f
to podman machine rm and the machine will be stopped and removed without
confirmations.
Fixes: #13448
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
This option was requested so that users could specify alternate
locations to find context directories for each image build. It
requites the --build option to be set.
Partion Fix: https://github.com/containers/podman/issues/12485
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If you run `podman play kube` on a yaml file that only contains
configMaps, podman will fail with the error:
Error: YAML document does not contain any supported kube kind
This is not strictly true; configMaps are a supported kube kind. The
problem is that configMaps aren't a standalone entity. They have to be
used in a container somewhere, otherwise they don't do anything.
This change adds a new message in the case when there only configMaps
resources. It would be helpful if podman reported which configMaps are
unused on every invocation of kube play. However, even if that feedback
were added, this new error messages still helpfully explains the reason
that podman is not creating any resources.
[NO NEW TESTS NEEDED]
Signed-off-by: Jordan Christiansen <xordspar0@gmail.com>
Generating unit files for a pod requires the pod to be created with an
infra container (see `--infra=true`). An infra container runs across
the entire lifespan of a pod and is hence required for systemd to manage
the life cycle of the pod's main unit.
This issue came up on the mailing list.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Allow users to commit containers into a single layer.
Usage
```bash
podman container commit --squash <name>
```
Signed-off-by: Aditya R <arajan@redhat.com>
`podman play kube` tries to build images even if `--build` is set to
false so lets honor that and make `--build` , `true` by default so it
matches the original behviour.
Signed-off-by: Aditya R <arajan@redhat.com>
podman container clone takes the id of an existing continer and creates a specgen from the given container's config
recreating all proper namespaces and overriding spec options like resource limits and the container name if given in the cli options
this command utilizes the common function DefineCreateFlags meaning that we can funnel as many create options as we want
into clone over time allowing the user to clone with as much or as little of the original config as they want.
container clone takes a second argument which is a new name and a third argument which is an image name to use instead of the original container's
the current supported flags are:
--destroy (remove the original container)
--name (new ctr name)
--cpus (sets cpu period and quota)
--cpuset-cpus
--cpu-period
--cpu-rt-period
--cpu-rt-runtime
--cpu-shares
--cpuset-mems
--memory
--run
resolves#10875
Signed-off-by: cdoern <cdoern@redhat.com>
Signed-off-by: cdoern <cbdoer23@g.holycross.edu>
Signed-off-by: cdoern <cdoern@redhat.com>
Add some docs about the different network backends. Also remove the CNI
word from network since we refer to either a netavark or CNI config.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
separated cgroupNS sharing from setting the pod as the cgroup parent,
made a new flag --share-parent which sets the pod as the cgroup parent for all
containers entering the pod
remove cgroup from the default kernel namespaces since we want the same default behavior as before which is just the cgroup parent.
resolves#12765
Signed-off-by: cdoern <cdoern@redhat.com>
Signed-off-by: cdoern <cbdoer23@g.holycross.edu>
Signed-off-by: cdoern <cdoern@redhat.com>
podman system prune should also remove all networks. When we want to
users to migrate to the new network stack we recommend to run podman
system reset. However this did not remove networks and if there were
still networks around we would continue to use cni since this was
considered an old system.
There is one exception for the default network. It should not be removed
since this could cause other issues when it no longer exists. The
network backend detection logic ignores the default network so this is
fine.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Document the recognized `schema` types that can be used in a value
passed to the `--url` command line flag.
[CI:DOCS]
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
by default slirp4netns uses the tap0 device. When slirp4netns is
used, use that device by default instead of eth0.
Closes: https://github.com/containers/podman/issues/11695
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Often users want their overlayed volumes to be `non-volatile` in nature
that means that same `upper` dir can be re-used by one or more
containers but overall of nature of volumes still have to be `overlay`
so work done is still on a overlay not on the actual volume.
Following PR adds support for more advanced options i.e custom `workdir`
and `upperdir` for overlayed volumes. So that users can re-use `workdir`
and `upperdir` across new containers as well.
Usage
```console
$ podman run -it -v myvol:/data:O,upperdir=/path/persistant/upper,workdir=/path/persistant/work alpine sh
```
Signed-off-by: Aditya R <arajan@redhat.com>
podman network create --subnet, --gateway and --ip-range can now be
specified multiple times to join the network to more than one subnet.
This is very useful if you want to use a dual stack network and assign a
fixed ipv4 and ipv6 subnet. The order of the options is important here,
the first --gateway/--ip-range will be assigned to the first subnet and
so on.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
