[
https://issues.apache.org/jira/browse/CLOUDSTACK-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15444715#comment-15444715
]
ASF GitHub Bot commented on CLOUDSTACK-9451:
--------------------------------------------
Github user jburwell commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1635#discussion_r76550534
--- Diff:
engine/api/src/org/apache/cloudstack/engine/cloud/entity/api/VirtualMachineEntity.java
---
@@ -115,6 +115,12 @@ String reserve(DeploymentPlanner plannerToUse,
@BeanParam DeploymentPlan plan, E
boolean stop(String caller) throws ResourceUnavailableException,
CloudException;
/**
+ * Stop the virtual machine, optionally force
+ *
+ */
+ boolean stop(String caller, boolean forced) throws
ResourceUnavailableException, CloudException;
--- End diff --
@nathanejohnson I wasn't thinking to change any of the existing code. I am
just interested in avoiding incurring any more flag argument technical debt.
In terms of testing, this change is not hypervisor specific. Therefore, a
test case that utilizes the simulator might be a more fruitful path. @rhtyd
may have some thoughts as to how you could accomplish it.
> stopVirtualMachine ignores forced parameter
> -------------------------------------------
>
> Key: CLOUDSTACK-9451
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9451
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Management Server
> Affects Versions: 4.8.0, 4.9.0
> Reporter: Nathan Johnson
> Priority: Minor
>
> As reported by Jeff Hair from the mailing list:
> Hi,
> I'm looking at the documentation and then the code for stopVirtualMachine.
> The forced parameter is passed down into the VM manager, where it seems to
> be ignored. This means that cleanupEvenIfFailed during VM stop will always
> be false, despite what the API command says. Going back to commit a4f4c986
> in 2013, we can see that the forced parameter was used. During subsequent
> refactoring, this seems to have vanished.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
