Kelven Thanks for the response,
As it stands, the serial operations - even for storage maintenance - are unbearably slow - especially if your storage can handle many more concurrent tasks Same applies for host maintenance mode, or any other operation like VM creation/deployment process. Everything is done in sequence. This approach is probably OK for small environments, but for really large implementations - when you need to spin instance up and down without waiting for a really long queue, or some other operation to complete . For example, just now a colleague of mine added a windows template, at the same time I decide to provision more linux host. His windows template is about 5 GB in size, he kicked of his tasks for the first time, while I kicked off mine right after him. As the result, I had to wait for his template to be initially deployed first, before my job can start. His job took about 20-30 minutes, my job takes less than 30 seconds. I understand this maybe a corner case, but our SLA can get really skewed if someone decides to add a new large sized template. If template additions are automated, we can go into a swing state on timing. Like you mentioned, we need more concurrency. Thanks ilya -----Original Message----- From: Kelven Yang [mailto:kelven.y...@citrix.com] Sent: Tuesday, April 02, 2013 1:27 PM To: dev@cloudstack.apache.org Subject: Re: [VMWARE]Any way to allow concurrent operations? We don't use queue facility/concurrency management within CloudStack extensively for now, the orchestration flow (i.e., putting storage into maintenance process) should launch concurrent tasks and manage it properly to achieve maximum of concurrency without breaking integrity of the operation. We do need to add more convenient facilities at framework level to enable these apparently needed features in various individual orchestration flows. Currently we write most of orchestration flows in a sequential execution manner. Kelven On 4/2/13 8:12 AM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >Edison was saying something about executeInSequence, causing the serial >operations, and how it was a compatibility thing. He said he removed it >once as a test and it seemed to work for concurrent operations on KVM, >but I don't know much about it. Just thought it was worth mentioning. > > >On Tue, Apr 2, 2013 at 9:06 AM, Chip Childers ><chip.child...@sungard.com>wrote: > >> On Tue, Apr 02, 2013 at 02:56:24PM +0000, Musayev, Ilya wrote: >> > Long story short - due to the fact, we do things serially, any mass >> operation will be queued, and may take very long time to complete. >> > >> > We need to improve this area, as its going to be one of the major >> complaints in the near future for corporate users that run vmware. >> >> Sounds like something that we should create as an "Improvement" ticket. >>
