cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9652) Job framework - Cancelling async jobs
Date Thu, 15 Dec 2016 19:01:02 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752193#comment-15752193
] 

ASF GitHub Bot commented on CLOUDSTACK-9652:
--------------------------------------------

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?


> Job framework - Cancelling async jobs
> -------------------------------------
>
>                 Key: CLOUDSTACK-9652
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9652
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>            Reporter: Rajani Karuturi
>            Assignee: Rajani Karuturi
>
> enable cancellation of long running or subsequent queued up async jobs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message