On 10/3/13 9:25 AM, "Koushik Das" <koushik....@citrix.com> wrote:
>Alena,
>I see that you had added this config setting. Any specific reason that
>this only for Start/Stop/Copy and not for all the commands as Alex
>mentioned? The name of the setting looks generic.
Because these are the commands for which hypervisors support parallel
execution for sure (tested by QA on Xen/KVM/VmWare).
As all our commands are generic, and not hypervisor specific, you have to
be very careful if decide to enable parallel execution for MigrateCommand
and test it on all the hypervisors CS supports.
-Alena.
>
>-Koushik
>
>On 03-Oct-2013, at 8:10 PM, Alex Ough <alex.o...@sungard.com> wrote:
>
>> Hi Koushik,
>>
>> Thanks for your reply, but unfortunately, this setting does NOT cover
>> 'MigrateCommand'.
>> As you specified, it seems to be effective only in
>>Start/Stop/CopyCommand.
>>
>> So can we include 'MigrateCommand' in that setting?
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Wed, Oct 2, 2013 at 11:44 PM, Koushik Das <koushik....@citrix.com>
>>wrote:
>>
>>> It is already a global setting in 4.2. The name of the setting is
>>> "execute.in.sequence.hypervisor.commands".
>>>
>>> Check out Config.java
>>>
>>> ExecuteInSequence("Advanced", ManagementServer.class, Boolean.class,
>>> "execute.in.sequence.hypervisor.commands", "true", "If set to true,
>>> StartCommand, StopCommand, CopyCommand will be synchronized on the
>>>agent
>>> side." +
>>> " If set to false, these commands become asynchronous. Default value
>>> is true.", null),
>>>
>>>
>>> -Koushik
>>>
>>> On 02-Oct-2013, at 10:43 PM, Alex Ough <alex.o...@sungard.com<mailto:
>>> alex.o...@sungard.com>> wrote:
>>>
>>> Thanks for the reply, Marcus.
>>>
>>> What about the option #3, which is to make it as a global setting?
>>> I think it can prevent side effects if exist.
>>>
>>> Alex Ough
>>>
>>>
>>> On Wed, Oct 2, 2013 at 11:37 AM, Marcus Sorensen <shadow...@gmail.com
>>> <mailto:shadow...@gmail.com>>wrote:
>>>
>>> Not sure. I don't know the history well enough to know if there were
>>> issues in the past, it might be that some hypervisors were fine and
>>> others weren't.
>>>
>>> On Wed, Oct 2, 2013 at 9:21 AM, Alex Ough
>>><alex.o...@sungard.com<mailto:
>>> alex.o...@sungard.com>> wrote:
>>> Marcus/Kelven,
>>>
>>> Any thoughts on my suggestions?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough
>>><alex.o...@sungard.com<mailto:
>>> alex.o...@sungard.com>>
>>> wrote:
>>>
>>> Oh, sorry for the confusion. I must have reversed the flags.
>>> As Kelven pointed, it is set as 'TRUE', which makes the process as
>>> sequential.
>>>
>>> So my questions are
>>> 1. If there is any reason why the method have been defined to return
>>> 'TRUE' always?
>>> 2. Do we expect any side effects and/or malfunctioning if we change it
>>> to
>>> returning 'FALSE'?
>>> 3. For a resolution without breaking possible flows, can we add the
>>> value
>>> of 'executeInSequence' to the global setting if #2 answers YES?
>>>
>>>
>>> On Tue, Sep 24, 2013 at 11:19 AM, Marcus Sorensen <shadow...@gmail.com
>>> <mailto:shadow...@gmail.com>>
>>> wrote:
>>>
>>> I thought executeInSequence of 'true' made it go serially, or
>>> sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
>>> August of 2010:
>>>
>>> 2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends
>>> Command
>>> {
>>> 2010-08-11 09:13:29 -0700 20) String vmName;
>>> 2010-08-11 09:13:29 -0700 21) String destIp;
>>> 2011-08-10 10:26:04 -0700 22) String hostGuid;
>>> 2010-08-11 09:13:29 -0700 23) boolean isWindows;
>>> 2010-08-11 09:13:29 -0700 24)
>>> 2010-08-11 09:13:29 -0700 25)
>>> 2010-08-11 09:13:29 -0700 26) protected MigrateCommand() {
>>> 2010-08-11 09:13:29 -0700 27) }
>>> 2012-12-03 22:06:41 -0800 28)
>>> 2010-08-11 09:13:29 -0700 29) public MigrateCommand(String vmName,
>>> String destIp, boolean isWindows)
>>> 2010-08-11 09:13:29 -0700 30) this.vmName = vmName;
>>> 2010-08-11 09:13:29 -0700 31) this.destIp = destIp;
>>> 2010-08-11 09:13:29 -0700 32) this.isWindows = isWindows;
>>> 2010-08-11 09:13:29 -0700 33) }
>>> 2012-12-03 22:06:41 -0800 34)
>>> 2010-08-11 09:13:29 -0700 35) public boolean isWindows() {
>>> 2010-08-11 09:13:29 -0700 36) return isWindows;
>>> 2010-08-11 09:13:29 -0700 37) }
>>> 2012-12-03 22:06:41 -0800 38)
>>> 2010-08-11 09:13:29 -0700 39) public String getDestinationIp() {
>>> 2010-08-11 09:13:29 -0700 40) return destIp;
>>> 2010-08-11 09:13:29 -0700 41) }
>>> 2012-12-03 22:06:41 -0800 42)
>>> 2010-08-11 09:13:29 -0700 43) public String getVmName() {
>>> 2010-08-11 09:13:29 -0700 44) return vmName;
>>> 2010-08-11 09:13:29 -0700 45) }
>>> 2012-12-03 22:06:41 -0800 46)
>>> 2011-08-10 10:26:04 -0700 47) public void setHostGuid(String guid)
>>> {
>>> 2011-08-10 10:26:04 -0700 48) this.hostGuid = guid;
>>> 2011-08-10 10:26:04 -0700 49) }
>>> 2012-12-03 22:06:41 -0800 50)
>>> 2011-08-10 10:26:04 -0700 51) public String getHostGuid() {
>>> 2011-08-10 10:26:04 -0700 52) return this.hostGuid;
>>> 2011-08-10 10:26:04 -0700 53) }
>>> 2010-08-11 09:13:29 -0700 54)
>>> 2010-08-11 09:13:29 -0700 55) @Override
>>> 2010-08-11 09:13:29 -0700 56) public boolean executeInSequence() {
>>> 2010-08-11 09:13:29 -0700 57) return true;
>>> 2010-08-11 09:13:29 -0700 58) }
>>> 2010-08-11 09:13:29 -0700 59) }
>>>
>>> On Tue, Sep 24, 2013 at 9:58 AM, Chip Childers
>>> <chip.child...@sungard.com<mailto:chip.child...@sungard.com>> wrote:
>>> Hey Kelven - This topic was discussed briefly in the past [1]. Are
>>> you
>>> able to provide any thoughts on Alex's ideas below?
>>>
>>> -chip
>>>
>>>
>>> [1] http://markmail.org/message/fznrszaswruvlmuy
>>>
>>>
>>>
>>> On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
>>> For a resolution without breaking possible flows, I'd like to add
>>> the
>>> value
>>> of 'executeInSequence' to the global setting.
>>> Is there any reason not to do this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough
>>><alex.o...@sungard.com<mailto:
>>> alex.o...@sungard.com>>
>>> wrote:
>>>
>>> All,
>>>
>>> After a little more investigation, I found that the
>>> 'MigrateCommand'
>>> defined its 'executeInSequence' method to return 'FALSE', which
>>> seems to
>>> make the vm migrations as serial even if the migration requests
>>> are
>>> dispatched to ha_worker in parallel.
>>> You can confirm this in line 56 of
>>> '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
>>>
>>> So my question is if there is any reason why the method have been
>>> defined to return 'FALSE' always?
>>> And do we expect any side effects and/or malfunctioning if we
>>> change
>>> it to
>>> returning 'TRUE'?
>>>
>>> Any answers/comments will be very appreciated.
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough <
>>> alex.o...@sungard.com<mailto:alex.o...@sungard.com>>
>>> wrote:
>>>
>>> I checked the vm migration when their host is set to a
>>> maintenance
>>> mode
>>> and found that even if the orchestration layer fires the each vm
>>> migration
>>> at the same time using a ha_worker thread, the actual migration
>>> seems to be
>>> executed serially.
>>>
>>> Is this what we expect? And if so, any chance to make the actual
>>> migrations in parallel?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
