Re: [PROPOSAL] Virtual Router aggregated execution
+1. * The guideline is not clear as to when a developer should use this executor. Why not use it all the time (even for a single command) * Are there any issues when there are multiple management servers involved? * Any threading concerns? That is, multiple threads are attempting to update the VR, some are using the aggregated approach, some are not. * What is the default value of aggregated period? * What if the caller dies before calling completeAggregatedExecution * what is the queue mechanism? LinkedBlockingQueue? * Any impact on the agent thread pool size? Does this use its own thread pool? * Can we also address the case of restoring state to a VR when restarting the VR outside of CloudStack. On 2/6/14 5:03 PM, Sheng Yang sh...@yasker.org wrote: Hi Devs, Here I'd like to introduce this improvement of VR. https://issues.apache.org/jira/browse/CLOUDSTACK-6047 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggr egated+command+execution In short, we would speed up VR's rebooting and re-creating, by aggregated execution the CloudStack configuration commands when booting up. Hopefully we can get it done in O(1) rather than O(n)(which is current state). And to prepare for this work, I've get a long expected code refactor done. Now one VirtualRoutingResources would take over all the VR execution commands(rather than every hypervisor's resource). From now on, you would only need to modify one place in order to update VR commands. I've put some details of VR aggregated execution in the FS. Comments are welcome! --Sheng
Re: [PROPOSAL] Virtual Router aggregated execution
Thanks for the comment! On Fri, Feb 7, 2014 at 3:25 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: +1. * The guideline is not clear as to when a developer should use this executor. Why not use it all the time (even for a single command) The mechanism behind is NOT a producer-consumer model. It's just a queue(or a list) to delay the commands execution for now. Only the code would generated a large number of commands would need to use this, and basically that's the VR reboot/re-create at this time. * Are there any issues when there are multiple management servers involved? It would remain the same as before. One VR(host) would only operated by one mgmt server, the other one would reroute all the related commands to the mgmt server in charge. And as soon as aggregated execution started, it would block all the commands at least in VR level(also in the host queue if network.element.sequence.execution is true). * Any threading concerns? That is, multiple threads are attempting to update the VR, some are using the aggregated approach, some are not. It is not a multithread solution in my mind. One queue for one VR, and would be created only prepare func called. All the following commands, no matter from which thread, would goes to this queue(by hooking sendCommandsToRouter in VR), wait until complete func called(which is expected quite soon). * What is the default value of aggregated period? No default, commands would wait until complete func called. * What if the caller dies before calling completeAggregatedExecution As noted in the spec, exception handler should call abortAggregatedExecution(). As design for VR booting up period, one failure would means VR fail to boot up. And, before commands send to VR, all the exception should be handled by mgmt server. I don't think there are any factor we cannot control would impact the command generation. But nonetheless, abortAggregatedExecution() is provided to clean up the queue and fail the execution. * what is the queue mechanism? LinkedBlockingQueue? Since it's not async, any ordered queue should be fine. Probably I should call it ArrayList... * Any impact on the agent thread pool size? Does this use its own thread pool? No thread pool. * Can we also address the case of restoring state to a VR when restarting the VR outside of CloudStack. No. That's not in the scope. I was willing to take a more radical approach for this work, but practically I would want to solve the 80% problem this time(which is VR booting/upgrading time). --Sheng On 2/6/14 5:03 PM, Sheng Yang sh...@yasker.org wrote: Hi Devs, Here I'd like to introduce this improvement of VR. https://issues.apache.org/jira/browse/CLOUDSTACK-6047 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggr egated+command+execution In short, we would speed up VR's rebooting and re-creating, by aggregated execution the CloudStack configuration commands when booting up. Hopefully we can get it done in O(1) rather than O(n)(which is current state). And to prepare for this work, I've get a long expected code refactor done. Now one VirtualRoutingResources would take over all the VR execution commands(rather than every hypervisor's resource). From now on, you would only need to modify one place in order to update VR commands. I've put some details of VR aggregated execution in the FS. Comments are welcome! --Sheng
Re: [PROPOSAL] Virtual Router aggregated execution
On Fri, Feb 7, 2014 at 4:48 PM, Sheng Yang sh...@yasker.org wrote: Thanks for the comment! On Fri, Feb 7, 2014 at 3:25 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: +1. * The guideline is not clear as to when a developer should use this executor. Why not use it all the time (even for a single command) The mechanism behind is NOT a producer-consumer model. It's just a queue(or a list) to delay the commands execution for now. Only the code would generated a large number of commands would need to use this, and basically that's the VR reboot/re-create at this time. * Are there any issues when there are multiple management servers involved? It would remain the same as before. One VR(host) would only operated by one mgmt server, the other one would reroute all the related commands to the mgmt server in charge. And as soon as aggregated execution started, it would block all the commands at least in VR level(also in the host queue if network.element.sequence.execution is true). * Any threading concerns? That is, multiple threads are attempting to update the VR, some are using the aggregated approach, some are not. It is not a multithread solution in my mind. One queue for one VR, and would be created only prepare func called. All the following commands, no matter from which thread, would goes to this queue(by hooking sendCommandsToRouter in VR), wait until complete func called(which is expected quite soon). * What is the default value of aggregated period? No default, commands would wait until complete func called. * What if the caller dies before calling completeAggregatedExecution As noted in the spec, exception handler should call abortAggregatedExecution(). As design for VR booting up period, one failure would means VR fail to boot up. And, before commands send to VR, all the exception should be handled by mgmt server. I don't think there are any factor we cannot control would impact the command generation. But nonetheless, abortAggregatedExecution() is provided to clean up the queue and fail the execution. * what is the queue mechanism? LinkedBlockingQueue? Since it's not async, any ordered queue should be fine. Probably I should call it ArrayList... Rethink about this. The input of queue can potentially become async, say if e.g. some other commands was added by other threads, so it's still better to get a LinkedBlockingQueue. --Sheng * Any impact on the agent thread pool size? Does this use its own thread pool? No thread pool. * Can we also address the case of restoring state to a VR when restarting the VR outside of CloudStack. No. That's not in the scope. I was willing to take a more radical approach for this work, but practically I would want to solve the 80% problem this time(which is VR booting/upgrading time). --Sheng On 2/6/14 5:03 PM, Sheng Yang sh...@yasker.org wrote: Hi Devs, Here I'd like to introduce this improvement of VR. https://issues.apache.org/jira/browse/CLOUDSTACK-6047 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggr egated+command+execution In short, we would speed up VR's rebooting and re-creating, by aggregated execution the CloudStack configuration commands when booting up. Hopefully we can get it done in O(1) rather than O(n)(which is current state). And to prepare for this work, I've get a long expected code refactor done. Now one VirtualRoutingResources would take over all the VR execution commands(rather than every hypervisor's resource). From now on, you would only need to modify one place in order to update VR commands. I've put some details of VR aggregated execution in the FS. Comments are welcome! --Sheng
[PROPOSAL] Virtual Router aggregated execution
Hi Devs, Here I'd like to introduce this improvement of VR. https://issues.apache.org/jira/browse/CLOUDSTACK-6047 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggregated+command+execution In short, we would speed up VR's rebooting and re-creating, by aggregated execution the CloudStack configuration commands when booting up. Hopefully we can get it done in O(1) rather than O(n)(which is current state). And to prepare for this work, I've get a long expected code refactor done. Now one VirtualRoutingResources would take over all the VR execution commands(rather than every hypervisor's resource). From now on, you would only need to modify one place in order to update VR commands. I've put some details of VR aggregated execution in the FS. Comments are welcome! --Sheng
Re: [PROPOSAL] Virtual Router aggregated execution
On Feb 6, 2014, at 8:03 PM, Sheng Yang sh...@yasker.org wrote: Hi Devs, Here I'd like to introduce this improvement of VR. https://issues.apache.org/jira/browse/CLOUDSTACK-6047 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Virtual+Router+aggregated+command+execution In short, we would speed up VR's rebooting and re-creating, by aggregated execution the CloudStack configuration commands when booting up. Hopefully we can get it done in O(1) rather than O(n)(which is current state). And to prepare for this work, I've get a long expected code refactor done. Now one VirtualRoutingResources would take over all the VR execution commands(rather than every hypervisor's resource). From now on, you would only need to modify one place in order to update VR commands. I've put some details of VR aggregated execution in the FS. Comments are welcome! --Sheng This is a awesome improvement. +1 from me.
