Skip to content
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

Open
wants to merge 35 commits into
base: main
Choose a base branch
from
Open

Add --force argument to the stop command #1946

wants to merge 35 commits into from

Conversation

luis4a0
Copy link
Contributor

@luis4a0 luis4a0 commented Jan 28, 2021

Add a new parameter to force the shutdown instances (i.e., power down them).

Fixes #1909, Fixes #2492

@townsend2010
Copy link
Contributor

Hey @luis4a0,

I know this is still in draft, but I always envisioned just adding a bool force flag to shutdown() and stop() (it also can be argued that either shutdown() or stop() can be dropped altogether, but that's for a different day). That way, you are not having to duplicate any special handling or logic that you are currently doing if some of the force_shutdown() implementations.

@codecov
Copy link

codecov bot commented Jan 28, 2021

Codecov Report

Attention: Patch coverage is 91.79104% with 11 lines in your changes missing coverage. Please review.

Project coverage is 88.90%. Comparing base (812f076) to head (f503968).

Files Patch % Lines
src/daemon/daemon.cpp 8.33% 11 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

@luis4a0
Copy link
Contributor Author

luis4a0 commented Jan 29, 2021

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.

Base automatically changed from master to main March 3, 2021 13:41
@luis4a0 luis4a0 force-pushed the add-force-stop branch 2 times, most recently from 36d6cec to a4f04ff Compare May 26, 2021 14:30
@sharder996 sharder996 marked this pull request as ready for review August 19, 2022 15:56
@sharder996
Copy link
Contributor

Added a few small changes; mostly refactoring with the current state of main and some wiring that got missed.

Fixes #2492

and

#2693 can be closed as its no longer needed

@ricab
Copy link
Collaborator

ricab commented Jan 30, 2023

Once this is in, I think we should also change delete such that running instances get force-stopped if a regular stop is not enough. I don't think it makes a lot of sense for deleted instances to keep running...

Copy link
Collaborator

@ricab ricab left a 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.

src/platform/backends/qemu/qemu_virtual_machine.cpp Outdated Show resolved Hide resolved
src/client/cli/cmd/stop.cpp Outdated Show resolved Hide resolved
luis4a0 and others added 28 commits June 20, 2024 13:02
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.
Copy link
Contributor

@andrei-toterman andrei-toterman left a 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.

Comment on lines +143 to +146
mp::BaseVirtualMachine::BaseVirtualMachine(VirtualMachine::State state,
const std::string& vm_name,
const SSHKeyProvider& key_provider,
const Path& instance_dir)
Copy link
Contributor

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?

Copy link
Collaborator

@ricab ricab Jun 21, 2024

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 .cpps. 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.

Comment on lines +384 to +387
if (state != State::off)
{
state = State::off;
}
Copy link
Contributor

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?

Comment on lines +368 to +371
lock.unlock();
vm_process->kill();
lock.lock();
state_wait.wait(lock, [this] { return vm_process == nullptr; });
Copy link
Contributor

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.

Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants