Remove --sync flag from `podman rm`

Per discussion with Dan, it would be better to automatically
handle potential runtime errors by automatically syncing if they
occur. Retaining the flag for `ps` makes sense, as we won't even
be calling the OCI runtime and as such won't see errors if the
state desyncs, but rm can be handled automatically.

The automatic desync handling code will take some additional work
so we'll land this as-is (sync on ps is enough to solve most
desync issues).

Signed-off-by: Matthew Heon <mheon@redhat.com>
This commit is contained in:
Matthew Heon 2018-12-05 09:25:44 -05:00
parent b945d9128a
commit e5335fd74c
3 changed files with 0 additions and 18 deletions

View File

@ -20,10 +20,6 @@ var (
Usage: "Force removal of a running container. The default is false",
},
LatestFlag,
cli.BoolFlag{
Name: "sync",
Usage: "Sync container state with OCI runtime before removing",
},
cli.BoolFlag{
Name: "volumes, v",
Usage: "Remove the volumes associated with the container (Not implemented yet)",
@ -77,12 +73,6 @@ func rmCmd(c *cli.Context) error {
for _, container := range delContainers {
con := container
f := func() error {
if c.Bool("sync") {
if err := con.Sync(); err != nil {
return err
}
}
return runtime.RemoveContainer(ctx, con, c.Bool("force"))
}

View File

@ -1828,7 +1828,6 @@ _podman_rm() {
-h
--latest
-l
--sync
--volumes
-v
"

View File

@ -24,13 +24,6 @@ Remove all containers. Can be used in conjunction with -f as well.
Instead of providing the container name or ID, use the last created container. If you use methods other than Podman
to run containers such as CRI-O, the last started container could be from either of those methods.
**--sync**
Force a sync of container state with the OCI runtime before attempting to remove the container.
In some cases, a container's state in the runtime can become out of sync with Podman's state,
which can cause Podman to refuse to remove containers because it believes they are still running.
A sync will resolve this issue.
**--volumes, -v**
Remove the volumes associated with the container. (Not yet implemented)