+1
On 1/31/13 8:07 PM, "Murali Reddy" <murali.re...@citrix.com> wrote:
>
>Kishan,
>
>Lets work on leveraging events-framwork for account-sync post merge of
>both features. For now go ahead with the merge if there are no concerns
>other than using events-framework.
>
>Thanks,
>Murali
>
>On 01/02/13 8:12 AM, "Kishan Kavala" <kishan.kav...@citrix.com> wrote:
>
>>
>>
>>On 01-Feb-2013, at 12:51 AM, "Chiradeep Vittal"
>><chiradeep.vit...@citrix.com> wrote:
>>
>>>
>>>
>>> On 1/31/13 9:21 AM, "Kishan Kavala" <kishan.kav...@citrix.com> wrote:
>>>
>>>>
>>>>
>>>> On 31-Jan-2013, at 9:36 PM, "Chip Childers"
>>>><chip.child...@sungard.com>
>>>> wrote:
>>>>
>>>>> On Jan 31, 2013, at 5:56 AM, Murali Reddy <murali.re...@citrix.com>
>>>>> wrote:
>>>>>
>>>>>> On 30/01/13 11:31 PM, "Chiradeep Vittal"
>>>>>><chiradeep.vit...@citrix.com>
>>>>>> wrote:
>>>>>>
>>>>>>> For the account sync, we can make use of the new event framework:
>>>>>>> instead
>>>>>>> of calling account sync inline with account creation, simply emit
>>>>>>>an
>>>>>>> event.
>>>>>>> The event can be consumed by the account sync service.
>>>>>>
>>>>>> Chiradeep,
>>>>>>
>>>>>> It's good idea to use events framework to sync account across the
>>>>>> regions.
>>>>>> But, a message broker is optional infrastructure component now,
>>>>>>unless
>>>>>> one
>>>>>> wants to use event notifications. This appraoch could be one of the
>>>>>> options in my opinion.
>>>>>>
>>>>>> Thanks,
>>>>>> Murali
>>>>>
>>>>> If it makes the region feature more robust and operationally useful,
>>>>> wouldn't it be reasonable to require that using multiple regions with
>>>>> a cloudstack installation require a queuing mechanism to make it work
>>>>> well?
>>>>
>>>> Changes based on the review are pushed to regions branch.
>>>> - separating RegionServiceImpl and RegionManagerImpl
>>>> - package name changed to org.apache.cloudstack.region
>>>> - added comments and unit tests
>>>> - added unique region name check
>>>> - branch is merged with latest master
>>>>
>>>> Account sync is the only outstanding issue right now.
>>>
>>> @Chip: agree with the sentiment.
>>> @Murali: can we have a default event bus implementation that does
>>>nothing?
>>>
>>> Instead of code like this:
>>> @Override
>>> public Account enableAccount(EnableAccountCmd cmd) {
>>> Account result = null;
>>> if(checkIsPropagate(cmd.getIsPropagate())){
>>> result = _accountMgr.enableAccount(cmd.getAccountName(),
>>> cmd.getDomainId(), cmd.getId());
>>> } else {
>>> result = _regionMgr.enableAccount(cmd.getAccountName(),
>>> cmd.getDomainId(), cmd.getId());
>>> }
>>> return result;
>>> }
>>>
>>>
>>> The account manager can simply do this:
>>> _eventBus.publish(AccountUpdateEvent)
>>>
>>
>>Can I go ahead with the merge now and change it to use event bus once we
>>have a default event bus implementation?
>>
>>Impact will be minimal for current dev setup which is same as single
>>Region setup and does not require any sync.
>
>
