Github user marcaurele commented on the issue:
https://github.com/apache/cloudstack/pull/1832
@karuturi Ok thanks for the clarifications, and it's the scenario I thought
about too. That being said, I'm currently thinking of a new approach for the
command sequencer because having implemented the live migration, the
non-parallel commands isn't optimal at all when you have long running
sequential commands on a hypervisor. And I tend to think that's the reason
behind your PR, isn't it? The way it's currently done is too simple (if a job
cannot be run in parallel on the HV, it will put in a queue any other coming
job that needs to run on this same HV). IMO this sequencing should take into
account what kind of job is coming and for which type of resources. For example
a security group update, a VM start and a migration for different VMs should be
able to run in parallel because they are unrelated. With today design, it isn't
possible.
So don't you think we're better of rewriting the sequencer to let more
commands being executed in parallel to avoid this bottleneck on the
AgentAttache? It would normally make the cancellation not needed in the way you
implemented it since less jobs will be queued.
If we wish to be able to cancel a job, IMHO it should cancel the job down
on the hypervisor too, thus clearing normally the resources involved as if the
execution didn't go well.
Otherwise, the way you implemented it. I would not let a job being cancel
if it has been sent to the hypervisor to clearly return to the user that it
wasn't cancelable anymore (you're too late! -> seq number isn't in `_requests`
anymore so it has been sent to the HV). I'm putting more comment in the code.
What do you think?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
