podman-machine-stop should block until the machine is in the target state #12815
Comments
|
@baude PTAL |
|
@rhatdan After some digging: Does the implementation of If yes: this issue could be closed or left open for a small documentation PR (I could submit a small PR to against the troubleshooting guide describing the difference in behavior pre-v4.0 and the 'workaround snippet' from the problem description above). If no: I could attempt a PR when I have more free time (extremely slammed at work right now) but the extent of my digging aroundI compared stop.go at diff --git a/cmd/podman/machine/stop.go b/cmd/podman/machine/stop.go
index 76ba85601..17969298b 100644
--- a/cmd/podman/machine/stop.go
+++ b/cmd/podman/machine/stop.go
@@ -1,11 +1,13 @@
-// +build amd64,!windows arm64,!windows
+//go:build amd64 || arm64
+// +build amd64 arm64
package machine
import (
+ "fmt"
+
"github.com/containers/podman/v3/cmd/podman/registry"
"github.com/containers/podman/v3/pkg/machine"
- "github.com/containers/podman/v3/pkg/machine/qemu"
"github.com/spf13/cobra"
)
@@ -31,20 +33,21 @@ func init() {
// TODO Name shouldn't be required, need to create a default vm
func stop(cmd *cobra.Command, args []string) error {
var (
- err error
- vm machine.VM
- vmType string
+ err error
+ vm machine.VM
)
vmName := defaultMachineName
if len(args) > 0 && len(args[0]) > 0 {
vmName = args[0]
}
- switch vmType {
- default:
- vm, err = qemu.LoadVMByName(vmName)
- }
+ provider := getSystemDefaultProvider()
+ vm, err = provider.LoadVMByName(vmName)
if err != nil {
return err
}
- return vm.Stop(vmName, machine.StopOptions{})
+ if err := vm.Stop(vmName, machine.StopOptions{}); err != nil {
+ return err
+ }
+ fmt.Printf("Machine %q stopped successfully\n", vmName)
+ return nil
} |
I think that was the original request: But not the implementation, afaik. |
|
@flouthoc @afbjorklund @baude Do we know if qemu is fully down at that point. Or are we just removing Podman's ability to communicate with it? |
|
not blocked on main ... i'm looking into it. |
|
I don't think it does a controlled shutdown (like: ACPI) at least, because "stop" completes in like a millisecond QMP
|
if users run podman machine stop && podman machine ls, the status of the machine in the subsequent ls command would running. now we wait for everything to complete for stop so that scripting is more accurate. Fixes: containers#12815 [NO NEW TESTS NEEDED] Signed-off-by: Brent Baude <[email protected]>
|
@justin-f-perez mind pulling main and trying it out? |
|
thanks everyone! @baude apologies I couldn't get to this sooner. I tried looking for instructions on building the podman client from source on macos, but all I could find for macos were the homebrew installation instructions. For future reference, is there a good way to update a homebrew installation to the tip of the containers/podman main branch? or instructions for building the client from source on macOS? thanks again! |
|
@justin-f-perez: |
|
I am reopening this bug because I have proof that on What is the proper way to stop the machine, so we can archive it? Is anyone is wondering, I am trying to make GHA actions/cache speedup the process of installing podman on GHA runners, as now it takes 13 minutes, 4x more than our effective test suite. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Looks like @ssbarnea fixed this. |
|
I will find-out soon, looking at https://github.com/ansible/vscode-ansible/runs/7952766944?check_suite_focus=true -- i assume that saving cache worked, reported as archiving >2GB. Now I only need to see that cache restore succeeds and that podman machine initialization is much faster. |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The interface for
podman machine startandpodman machine stopare inconsistent. The former blocks until the machine is in the target state, while the latter does not. (NOTE: this inconsistency is why I labeled this a bug and not a feature request.)podman machine stopbehavior causes many annoying problems which are illustrated below. Instead, it should block until the target state is reached (just like otherpodman machinecommands do.)Significance
Scripting
I never remember this inconsistency when I start scripting on a new project, and I've been burned by it multiple times. This was especially confusing the first time I encountered it; this cost (me personally) multiple hours of debug time.
User Experience
It's also very inconvenient for sending short snippets/advice to colleagues, e.g., this is bad advice because it results in an error:
Instead, I need to send "colleague" an entire script that correctly blocks or explain to them the inconsistencies on podman's behavior and how to check for whether the machine is actually stopped.
Onboarding
Requiring users to know these implementation details just to "turn it off and on again" is harmful to podman adoption. I'm not going to recommend that my organization adopt podman if I can't tell a junior developer how to perform a simple operation (restart podman machine) without a Zoom call.
Documentation
The differences in
start/stopblocking behavior aren't documented in any man pages. I checked:man podman-machineman podman-machine-stopman podman-machine-startI also checked the corresponding CLI help:
Backward compatibility
I can't think of any use case that would depend on
podmannot blocking. I suspect most users script against thepodmancli are using their own hacky waiting scripts. Thus, ifpodman machine stopwere just a noop in the case that the machine is already stopped, or blocking until the target state is reached in the case that the machine is running, I think this behavior change would be backward compatibile.If blocking becomes the new default behavior, users can still get
stopto not block the current process by backgrounding the command:podman machine stop &Furthermore, if
podman machine stopblocks, users can check whether the command actually completed by checking the status of the backgrounded job. In the current implementation, the fact that the background job exited is meaningless.If this behavior can't be implemented as default, I would be just as happy with a flag, e.g.:
podman machine stop --wait,podman machine stop --block, or similar. I'll probably still forget that flag, but it's a much easier fix to add a flag to the command than it is to replacepodman machine stopeverywhere with my own hacks.Steps to reproduce the issue
stop-and-list
This test case demonstrates that
podman machine stopdoes not block until it reaches the target state.start-and-list
This test case demonstrates that
podman machine startblocks until it reaches the target state.podman machine start && podman machine liststop-list-run-list-start
Naturally, you might think you can restart with a simple conjunction of
stopandstart, but you can't. You might also think "Currently running" means a podman machine is ready to receive work, but it doesn't.podman machine listtells us the machine is 'Currently running'. That's misleading (it's shutting down).podman machine startalso tells us 'VM already running'. That's misleading (it's shutting down).Actual results
podman machine stop does not block until the machine is stopped.
Expected results
I expect:
podman-machine-stopto block until it reaches the target state (i.e., if the machine is already stopped, return immediately; if the machine is not stopped, block until it stops).As a consequence:
podman machine stop && podman machine startto restart the podman VM (without "VM already started" errors)podman machine stop && podman machine listto indicate that that the machine is stopped (and for the machine to actually be stopped)Additional information
This is a typical example of how I deal with this problem currently, on a host that runs only a single podman machine.
Output of
podman version:Output of
podman info --debug:Package info
Tested with latest?
yes (using latest from homebrew)
Checked Podman Troubleshooting Guide?
yes,
podman machine stop(lack of) blocking is not mentioned anywhere.Additional environment details (AWS, VirtualBox, physical, etc.):
local machine
HW: 2020 M1 MacBook Pro
arch: arm64
OS: Big Sur (11.6.2)
shell: zsh
podman installed by: brew
The text was updated successfully, but these errors were encountered: