cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: [PROPOSAL] Virtual Router aggregated execution
Date Sat, 08 Feb 2014 01:59:11 GMT
On Fri, Feb 7, 2014 at 4:48 PM, Sheng Yang <sheng@yasker.org> wrote:

> Thanks for the comment!
>
> On Fri, Feb 7, 2014 at 3:25 PM, Chiradeep Vittal <
> Chiradeep.Vittal@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" <sheng@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message