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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to