Github user karuturi 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?
Yes, thats right.
> The way it's currently done is too simple (if a job cannot be run in
parallel on the HV, it will put in
> 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.
>
As you already said, with todays design it isn't possible. Rewriting is
obviously better. But, thats a bigger job. In the current design, this was the
only possible way to allow cloudstack to process queued up jobs.
> 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.
>
I agree. But, thats a huge task given the number of hypervisors we support
and their versions.
---
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.
---
