-
Notifications
You must be signed in to change notification settings - Fork 625
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --force
argument to the stop
command
#1946
base: main
Are you sure you want to change the base?
Conversation
Hey @luis4a0, I know this is still in draft, but I always envisioned just adding a |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1946 +/- ##
==========================================
+ Coverage 88.81% 88.90% +0.08%
==========================================
Files 253 254 +1
Lines 14121 14170 +49
==========================================
+ Hits 12542 12598 +56
+ Misses 1579 1572 -7 ☔ View full report in Codecov by Sentry. |
Hey @townsend2010, thanks a lot for your comment! What you propose makes complete sense, I'll finish testing if the commands I used indeed work to turn off VM's and then rework the code. |
1f21eac
to
3a7b09d
Compare
36d6cec
to
a4f04ff
Compare
b10bc1a
to
69ebeca
Compare
Once this is in, I think we should also change |
65903a3
to
708bd3a
Compare
41f273e
to
b1a5b88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @townsend2010, thanks for the PR! Not a proper review, but I was looking in order to base my work on top, so leaving a couple of comments.
4be3838
to
8ac8d93
Compare
8ac8d93
to
45dcacd
Compare
45dcacd
to
1861b89
Compare
This will make it explicit that the user wants to force stop an instance.
Change "Forced" to "Forcing" Co-authored-by: Ricardo Abreu <6698114+ricab@users.noreply.github.com> Signed-off-by: Chris Townsend <christopher.townsend@canonical.com>
If the instance is suspended when a force shutdown is issued, then delete the suspend image.
This will account for the case if an instance is starting and getting stuck when resuming from a suspend image.
This is fit in with the style used in other implementations.
ece9a6c
to
f503968
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, the code looks pretty good IMO. It went through many iterations already after all.
In terms of functionality:
- The main issue is QEMU deadlocking.
- The other smaller issue is libvirt not removing the suspended state on force stop. But given that we're talking more and more about removing libvirt, I'm not sure if it's worth spending too much time on this issue.
mp::BaseVirtualMachine::BaseVirtualMachine(VirtualMachine::State state, | ||
const std::string& vm_name, | ||
const SSHKeyProvider& key_provider, | ||
const Path& instance_dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like an opinion on this change of removing the enclosing multipass
namespace and adding mp::
to all the enclosed functions. IMO it only adds more width for no reason at all. Is it preferable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is largely a matter of preference. I personally prefer the fully qualified name in .cpp
s. Compilation units are usually long so it is easier understand functions' scope regardless of their position in the file. And when something is already declared in the header, I feel it is more intuitive to just refer to it with its full "path". But I also prefer indenting namespace contents (which we don't do), in which case this approach would tend to save space. In any case, consistency has its value too (it makes things more immediately recognizable) and I believe this is the de facto convention in Multipass.
if (state != State::off) | ||
{ | ||
state = State::off; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this different than just state = State::off
?
lock.unlock(); | ||
vm_process->kill(); | ||
lock.lock(); | ||
state_wait.wait(lock, [this] { return vm_process == nullptr; }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this leads to a deadlock if the callback for the signal emitted by kill()
does no execute before the lock()
.
Adding a vm_process->wait_for_finished()
before the lock.lock()
seems to solve the issue, but I'm not sure if that's a good solution or just a quick fix. Maybe some restructuring of the code could avoid this problem entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libvirt does not remove suspended state on force stop
Add a new parameter to force the shutdown instances (i.e., power down them).
Fixes #1909, Fixes #2492