But what if those resources are synced around regions prior to the upgrade? With the approach you suggest, the same resource will have different region id in each region¹s DB.
-Alena. On 6/4/14, 9:33 AM, "Alex Ough" <alex.o...@sungardas.com> wrote: >I thought about this and I think it is better to save the local region >uuid >because all resources are sure to be created in the local region, which is >#4. > >Thanks >Alex Ough > > >On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk < >alena.prokharc...@citrix.com> wrote: > >> Alex, one more bullet is needed. >> >> #5 During the DB upgrade all the account/domain/user records should be >> populated with ³originated_region_uuid² = one of the regions in the >>system. >> The region should be picked using ³region having smallest UUID² >>criteria. >> >> -alena. >> >> From: Alex Ough <alex.o...@sungardas.com> >> Date: Wednesday, June 4, 2014 at 5:28 AM >> >> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >> murali.re...@citrix.com>, Kishan Kavala <kishan.kav...@citrix.com>, " >> dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >> Subject: Re: Control event publishing in multi region setups >> >> All, >> >> Alex Huang, Alena and I had a conversation to find out the best >>solution >> for one remaining issue, >> which is to prevent the changes from being sent to remote regions even >> when resource changes are occurred in the local region during FullScan >> and these are what we decided. >> >> 1. A new parameter, 'originated_region_uuid', will be used to control >> the flow >> - during the realtime sync, the value will be the uuid of the local >> region to allow the changes to be transferred to remote regions, >> - during the full scan, the value will be the uuid of the remote >>region >> to prevent them from being transferred to remote regions even if the >>change >> was occurred in the local region. >> >> 2. To support this change, a new input param, 'originated_region_uuid', >> will be added to all methods to manage user/account/domain in >> AccountManager & DomainManager class. >> >> 3. To store the new input param value, a new field, >> 'originated_region_uuid', will be added to domain/account/user table and >> they will be populated with the current local region uuid when the >>fields >> are created during the schema changes because we can guarantee that the >> current user/account/domain resources were created in the local region. >> >> 4. The API interfaces to manage the user/account/domain will have an >> additional input param, 'originated_region_uuid', to support this >>change. >> >> Please let me know if you have any comments. >> Thanks >> Alex Ough >> >> >> On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk < >> alena.prokharc...@citrix.com> wrote: >> >>> Yes, I¹m back. Please check with Alex Huang what time he can be on the >>> call with you. I can join any time today/tomorrow. >>> >>> -Alena. >>> >>> From: Alex Ough <alex.o...@sungardas.com> >>> Date: Monday, June 2, 2014 at 9:49 AM >>> >>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>> murali.re...@citrix.com>, Kishan Kavala <kishan.kav...@citrix.com>, " >>> dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>> Subject: Re: Control event publishing in multi region setups >>> >>> Hi Alena, >>> >>> Did you get back from the vacation? >>> If so, let me know when it is the good time to discuss this. >>> >>> Thanks >>> Alex Ough >>> >>> >>> On Thu, May 15, 2014 at 9:02 AM, Alex Ough <alex.o...@sungardas.com> >>> wrote: >>> >>>> I know. That's why I asked before Alex Huang to let me know when he's >>>> available after he's coming back next week. >>>> >>>> Have a good vacation. >>>> Thanks >>>> Alex Ough >>>> >>>> >>>> On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk < >>>> alena.prokharc...@citrix.com> wrote: >>>> >>>>> Alex, I¹m on vacation tomorrow; leaving today at 2 pm. >>>>> >>>>> Thanks, >>>>> Alena. >>>>> >>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>> Date: Wednesday, May 14, 2014 at 1:18 PM >>>>> >>>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>>>> murali.re...@citrix.com>, Kishan Kavala <kishan.kav...@citrix.com>, " >>>>> dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>> Subject: Re: Control event publishing in multi region setups >>>>> >>>>> My meeting is being delayed, so let me know when you guys are >>>>> available from tomorrow. >>>>> >>>>> Thanks >>>>> Alex Ough >>>>> >>>>> >>>>> On Wed, May 14, 2014 at 3:05 PM, Alex Ough <alex.o...@sungardas.com> >>>>> wrote: >>>>> >>>>>> I have a meeting in 20 min which is estimated to end 1pm PST, so >>>>>>I'll >>>>>> let you know once it is over. >>>>>> >>>>>> >>>>>> On Wed, May 14, 2014 at 3:01 PM, Alena Prokharchyk < >>>>>> alena.prokharc...@citrix.com> wrote: >>>>>> >>>>>>> Alex, sure we can have a call. I¹m in the office till 2 pm PST >>>>>>> today. Send the meeting invitation to me and Alex. >>>>>>> >>>>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>>>> Date: Wednesday, May 14, 2014 at 11:33 AM >>>>>>> >>>>>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>>>>>> murali.re...@citrix.com>, Kishan Kavala >>>>>>><kishan.kav...@citrix.com>, " >>>>>>> dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>>>> Subject: Re: Control event publishing in multi region setups >>>>>>> >>>>>>> I think I forgot to mention this, but I think we should talk with >>>>>>> Alex Huang also because you need his approval. >>>>>>> So let me know when you guys are available and let's just stop >>>>>>> sending emails back and forth. >>>>>>> >>>>>>> Thanks >>>>>>> Alex Ough >>>>>>> >>>>>>> >>>>>>> On Wed, May 14, 2014 at 2:30 PM, Alex Ough >>>>>>><alex.o...@sungardas.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Alena, >>>>>>>> >>>>>>>> I think we should talk, so please let me know when you're >>>>>>>> available. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Alex Ough >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 14, 2014 at 1:36 PM, Alena Prokharchyk < >>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>> >>>>>>>>> Alex, we do understand how ³Full Scan² works and we know that >>>>>>>>> your component/other components using Full Scan, should be able >>>>>>>>>to >>>>>>>>> distinguish whether the event was generated locally or by >>>>>>>>>another region. >>>>>>>>> >>>>>>>>> Changing the event by enhancing it with ³Local² flag is not a >>>>>>>>> desired solution as its very specific to your feature, and we >>>>>>>>>should never >>>>>>>>> modify the CS code just to satisfy only a certain plugin/service >>>>>>>>>needs. The >>>>>>>>> same applies to introducing another method w/o event generation. >>>>>>>>> Both >>>>>>>>> solutions are incorrect, and I¹m against putting them to the CS. >>>>>>>>> >>>>>>>>> Here are the rules that should apply to account/domain/user >>>>>>>>> changes on the CS side: >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. The event should be generated regardless of who makes the >>>>>>>>> call >>>>>>>>> 2. The event should be light weight and contain the minimum >>>>>>>>> details object id/uuid/status. If we let third party >>>>>>>>>components to >>>>>>>>> enhance the events, they would grow exponentially and certain >>>>>>>>>details would >>>>>>>>> make sense just to specific plugin. So no changes to the >>>>>>>>>event object >>>>>>>>> unless its something generic and would make sense for all the >>>>>>>>>subscribers. >>>>>>>>> 3. If subscriber needs to get more details about the object >>>>>>>>> account/domain/user he needs to request those details by >>>>>>>>>calling >>>>>>>>> listAccount/listDomains/listUsers API after getting the >>>>>>>>>event. And object >>>>>>>>> itself should give you information about: >>>>>>>>> >>>>>>>>> >>>>>>>>> - Latest updates >>>>>>>>> - Who performed the latest update which region. >>>>>>>>> >>>>>>>>> So the solution for your plugin would be as Alex Huang suggested >>>>>>>>> originally add extra field to account/domain/user object >>>>>>>>>defining who did >>>>>>>>> the update. Copying his suggestion below: >>>>>>>>> >>>>>>>>> "Now the detail is in how do we know if an account is created or >>>>>>>>> propagated. For that, it can be done in a number of ways. I¹m >>>>>>>>>open to >>>>>>>>> which method. I would suggest that we add two fields to account: >>>>>>>>> origination region and original uuid. The create account API >>>>>>>>>takes an >>>>>>>>> optional fields for the origination region and origination >>>>>>>>>account uuid. >>>>>>>>> If these two parameters are not set in the API, the API set the >>>>>>>>> origination region to the current region and the original uuid >>>>>>>>>to the uuid >>>>>>>>> of the account. " >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alena. >>>>>>>>> >>>>>>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>>>>>> Date: Wednesday, May 14, 2014 at 6:44 AM >>>>>>>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>> >>>>>>>>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>>>>>>>> murali.re...@citrix.com>, Kishan Kavala >>>>>>>>><kishan.kav...@citrix.com>, >>>>>>>>> "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>>>>>> Subject: Re: Control event publishing in multi region setups >>>>>>>>> >>>>>>>>> Alena/Alex Hwang, >>>>>>>>> >>>>>>>>> I totally understand your concerns, but I'm afraid you guys >>>>>>>>>don't >>>>>>>>> seem to understand how the 'Full scan' works. >>>>>>>>> If I understood correctly, Alex Hwang's suggestion does NOT work >>>>>>>>> because it is NOT the matter of propagation. >>>>>>>>> The event subscribers that processes the Full Scan needs to >>>>>>>>>discard >>>>>>>>> all events even if they have the region value of 'Local'. >>>>>>>>> >>>>>>>>> So to resolve this issue, >>>>>>>>> 1. The methods to manage the domain/account/user resources needs >>>>>>>>>to >>>>>>>>> send events that include a kind of boolean flag that notify the >>>>>>>>>'Full Scan' >>>>>>>>> subscribers to discard the events even if the region value is >>>>>>>>>'Local' >>>>>>>>> 2. To add that flag into their events, the methods should have >>>>>>>>> additional input parameter for the flag value the caller can >>>>>>>>>assign along >>>>>>>>> with the region input param value of null >>>>>>>>> 3. Then what is the difference with having another method not to >>>>>>>>> generate event? >>>>>>>>> >>>>>>>>> Let me know if I'm missing any. >>>>>>>>> Thanks >>>>>>>>> Alex Ough >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, May 13, 2014 at 12:56 PM, Alena Prokharchyk < >>>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>>> >>>>>>>>>> Alex, how do you know that the data is useless? Only the >>>>>>>>>> recipient can make this judgement. In your case you know that >>>>>>>>>>the recipient >>>>>>>>>> your local region doesn¹t need this data, but you can¹t >>>>>>>>>>make this call >>>>>>>>>> on behalf of everybody else. Example of the possible scenario: >>>>>>>>>>somebody >>>>>>>>>> wants to perform user¹s update once corresponding account gets >>>>>>>>>>updated, >>>>>>>>>> within the same region. And they rely on in-memory bus to catch >>>>>>>>>> updateAccount event in order to execute updateUser operation. >>>>>>>>>>So the event >>>>>>>>>> always has to be published. >>>>>>>>>> >>>>>>>>>> The conclusion: Any update done to the account/domain/user, >>>>>>>>>> should generate the event. The recipient should make a decision >>>>>>>>>>whether to >>>>>>>>>> ignore the event, or process it further. Alex proposed to >>>>>>>>>>enhance the >>>>>>>>>> account/domain/user object with the field identifying who¹s >>>>>>>>>>triggered the >>>>>>>>>> upgrade to give more details to the recipient. >>>>>>>>>> >>>>>>>>>> -Alena. >>>>>>>>>> >>>>>>>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>>>>>>> Date: Monday, May 12, 2014 at 6:14 PM >>>>>>>>>> >>>>>>>>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>>>>>>>>> murali.re...@citrix.com>, Kishan Kavala >>>>>>>>>><kishan.kav...@citrix.com>, >>>>>>>>>> "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>>>>>>> Subject: Re: Control event publishing in multi region setups >>>>>>>>>> >>>>>>>>>> I'm not really sure why you think it is a bug. And why do you >>>>>>>>>> want to send data that is absolutely useless to the destination? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Alex Ough >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, May 12, 2014 at 6:19 PM, Alena Prokharchyk < >>>>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>>>> >>>>>>>>>>> Alex, I can¹t approve the current approach you use in your >>>>>>>>>>>fix. >>>>>>>>>>> The reason that there are bugs in the current CS code, and >>>>>>>>>>>therefore we can >>>>>>>>>>> contribute more to the buggy behavior, doesn¹t sound right to >>>>>>>>>>>me. And we >>>>>>>>>>> have 1 from Alex Huang on that as well. >>>>>>>>>>> >>>>>>>>>>> We either fix it as a part of this commit, or you can fix it >>>>>>>>>>> later. But it has to make it to 4.5, otherwise the original >>>>>>>>>>>fix will be >>>>>>>>>>> rolled back. You can finalize the approach with Alex, and I >>>>>>>>>>>will check in >>>>>>>>>>> your code as soon as its done, either before I go on vacation, >>>>>>>>>>>or after I¹m >>>>>>>>>>> back. >>>>>>>>>>> >>>>>>>>>>> -Alena. >>>>>>>>>>> >>>>>>>>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>>>>>>>> Date: Monday, May 12, 2014 at 3:13 PM >>>>>>>>>>> To: Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>>>> Cc: Alex Huang <alex.hu...@citrix.com>, Murali Reddy < >>>>>>>>>>> murali.re...@citrix.com>, Kishan Kavala >>>>>>>>>>><kishan.kav...@citrix.com>, >>>>>>>>>>> "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >>>>>>>>>>> >>>>>>>>>>> Subject: Re: Control event publishing in multi region setups >>>>>>>>>>> >>>>>>>>>>> That is not good, but I'm wondering if you can approve after >>>>>>>>>>> our conversation without consulting with Alex Hwang. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Alex Ough >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, May 12, 2014 at 2:37 PM, Alena Prokharchyk < >>>>>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> We do have to come to conclusion for this remaining issue >>>>>>>>>>>> before committing the patches below: >>>>>>>>>>>> (https://reviews.apache.org/r/20099/ and >>>>>>>>>>>> https://reviews.apache.org/r/17790/) >>>>>>>>>>>> >>>>>>>>>>>> Alex (Ough), I¹m going to be on vacation from May 15th till >>>>>>>>>>>> May 31st, if you and Alex(Huang) have your >>>>>>>>>>>>discussion/resolution while I¹m >>>>>>>>>>>> away, I can commit the patches only after I¹m back. >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> Alena. >>>>>>>>>>>> >>>>>>>>>>>> From: Alex Ough <alex.o...@sungardas.com> >>>>>>>>>>>> Date: Sunday, May 11, 2014 at 10:10 PM >>>>>>>>>>>> To: Alex Huang <alex.hu...@citrix.com> >>>>>>>>>>>> Cc: Murali Reddy <murali.re...@citrix.com>, Alena Prokharchyk >>>>>>>>>>>>< >>>>>>>>>>>> alena.prokharc...@citrix.com>, Kishan Kavala < >>>>>>>>>>>> kishan.kav...@citrix.com>, "dev@cloudstack.apache.org" < >>>>>>>>>>>> dev@cloudstack.apache.org> >>>>>>>>>>>> >>>>>>>>>>>> Subject: Re: Control event publishing in multi region setups >>>>>>>>>>>> >>>>>>>>>>>> Alex, >>>>>>>>>>>> >>>>>>>>>>>> It looks like I'd better wait until you're back because I'm >>>>>>>>>>>> afraid Alena seems to need your approval based on what I've >>>>>>>>>>>>been through. >>>>>>>>>>>> Let me know once you're back. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Alex Ough >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, May 10, 2014 at 12:50 PM, Alex Huang < >>>>>>>>>>>> alex.hu...@citrix.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Alex and Alena, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps, it¹s best you two get on the phone about this. I >>>>>>>>>>>>> don¹t see Alex understanding what I¹m saying over email so >>>>>>>>>>>>>there¹s no point >>>>>>>>>>>>> in me repeating it. I¹m not around next week and I think >>>>>>>>>>>>>Alena is out >>>>>>>>>>>>> after Wednesday. Something on Monday or Tuesday would be a >>>>>>>>>>>>>good idea or >>>>>>>>>>>>> you can wait for me to come back the week after. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.o...@sungardas.com] >>>>>>>>>>>>> *Sent:* Saturday, May 10, 2014 9:28 AM >>>>>>>>>>>>> *To:* Alex Huang >>>>>>>>>>>>> >>>>>>>>>>>>> *Cc:* Murali Reddy; Alena Prokharchyk; Kishan Kavala; >>>>>>>>>>>>> dev@cloudstack.apache.org >>>>>>>>>>>>> *Subject:* Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> And I'm really wondering if you understood how the 'Full >>>>>>>>>>>>>Scan' >>>>>>>>>>>>> works. It is absolutely internal operations. >>>>>>>>>>>>> >>>>>>>>>>>>> Why do we force to use the event generating methods when the >>>>>>>>>>>>> updates are only internal and never, ever, ever ... need >>>>>>>>>>>>>events? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know if there is any chance it needs to use the >>>>>>>>>>>>>events, >>>>>>>>>>>>> then I'll follow your suggestion. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Alex Ough >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, May 10, 2014 at 11:55 AM, Alex Ough < >>>>>>>>>>>>> alex.o...@sungardas.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I really don't know why you guys are making it complicated. >>>>>>>>>>>>> >>>>>>>>>>>>> The class has two different methods, one with 'event' >>>>>>>>>>>>>decorator >>>>>>>>>>>>> and the other without it. >>>>>>>>>>>>> >>>>>>>>>>>>> So the callers know which method to call depending on their >>>>>>>>>>>>> needs. >>>>>>>>>>>>> >>>>>>>>>>>>> And the each method will be called accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, May 10, 2014 at 6:13 AM, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> -1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I do not believe in the argument that says ³since there¹s >>>>>>>>>>>>> existing bad code, then I can check in code that also causes >>>>>>>>>>>>>regressions >>>>>>>>>>>>> for users.² If that¹s the case, what¹s the point of the >>>>>>>>>>>>>review? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> We¹ve offered a path forward already. Please reconsider >>>>>>>>>>>>>that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.o...@sungardas.com] >>>>>>>>>>>>> *Sent:* Friday, May 9, 2014 9:14 PM >>>>>>>>>>>>> *To:* Alex Huang >>>>>>>>>>>>> *Cc:* Murali Reddy; Alena Prokharchyk; Kishan Kavala; >>>>>>>>>>>>> dev@cloudstack.apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Subject:* Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Are we going to rolling this out? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 8, 2014 at 2:28 PM, Alex Ough < >>>>>>>>>>>>> alex.o...@sungardas.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> That's why there are 2 methods, one is that generates events >>>>>>>>>>>>> and the other not and there are already a few public methods >>>>>>>>>>>>>without event >>>>>>>>>>>>> decoration. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 8, 2014 at 2:25 PM, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Alex, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I did read this when you first proposed. I do understand the >>>>>>>>>>>>> two implementation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I understand that #2 is not activated via events but it >>>>>>>>>>>>>doesn¹t >>>>>>>>>>>>> mean #2 can just don¹t generate events. The blocker is >>>>>>>>>>>>>precisely with the >>>>>>>>>>>>> last sentence in #2 where it states #2 doesn¹t generate an >>>>>>>>>>>>>event when ³it >>>>>>>>>>>>> creates/updates/removes the resource in the local region². >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps an example would make this more clear. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Someone who deploys CloudStack sets up a process to listen to >>>>>>>>>>>>> account events. It is a simple audit process whose job is >>>>>>>>>>>>>to verify that >>>>>>>>>>>>> an account created in CloudStack is actually in their own >>>>>>>>>>>>>billing >>>>>>>>>>>>> database. The fact that #2 doesn¹t generate an event would >>>>>>>>>>>>>mean this >>>>>>>>>>>>> process would be broken for them. This is the regression >>>>>>>>>>>>>that causes the >>>>>>>>>>>>> blocker. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.o...@sungardas.com] >>>>>>>>>>>>> *Sent:* Thursday, May 8, 2014 11:02 AM >>>>>>>>>>>>> *To:* Alex Huang >>>>>>>>>>>>> *Cc:* Murali Reddy; Alena Prokharchyk; Kishan Kavala >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Subject:* Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alex, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I think you really review the wiki ( >>>>>>>>>>>>> >>>>>>>>>>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain- >>>>>>>>>>>>>Account-User+Sync+Up+Among+Multiple+Regions) >>>>>>>>>>>>> or the implemented codes. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> To help you understand, there are 2 synchronizations >>>>>>>>>>>>>supported >>>>>>>>>>>>> in this feature. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1. real time sync : This is what you may imagine and event >>>>>>>>>>>>> based. This is sending requests when they are >>>>>>>>>>>>>created/updated/removed in >>>>>>>>>>>>> the local region by subscribing their events. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2. full scan : This is NOT related with events and it is to >>>>>>>>>>>>> cover when the #1 sync is failed with any reason like >>>>>>>>>>>>>network failures. >>>>>>>>>>>>> With interval, it just scans all resources and compare them >>>>>>>>>>>>>with ones in >>>>>>>>>>>>> remote regions and if there is any missing in the local >>>>>>>>>>>>>region, it >>>>>>>>>>>>> creates/updates/removes the resource in the local region and >>>>>>>>>>>>>the NEW >>>>>>>>>>>>> METHODS I need are called because it is local region only >>>>>>>>>>>>>and no need to >>>>>>>>>>>>> have events. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'm hoping you understand the feature a little more and let >>>>>>>>>>>>>me >>>>>>>>>>>>> know if you need more information. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Alex Ough >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 8, 2014 at 1:43 PM, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Alex, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please know that the contribution is much appreciated. It is >>>>>>>>>>>>> not a case of whether or not Alena ³wants² or ³doesn¹t want² >>>>>>>>>>>>>to approve the >>>>>>>>>>>>> review. She can only approve if the design is sound and has >>>>>>>>>>>>>no regression >>>>>>>>>>>>> for existing deployments of CloudStack. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is a blocker because not publishing events when an >>>>>>>>>>>>>account >>>>>>>>>>>>> is propagated is actually an ³incorrect² behavior for >>>>>>>>>>>>>CloudStack. Any >>>>>>>>>>>>> functionality that acts on an account creation within the >>>>>>>>>>>>>region will face >>>>>>>>>>>>> regression. That¹s why it is not ³an additional feature² >>>>>>>>>>>>>and must be >>>>>>>>>>>>> fixed. Think of SunGuard itself. If it was depending on >>>>>>>>>>>>>the account >>>>>>>>>>>>> creation event and the next version of CloudStack suddenly >>>>>>>>>>>>>doesn¹t generate >>>>>>>>>>>>> the event consistently, would it not consider this a bug and >>>>>>>>>>>>>ask us to fix >>>>>>>>>>>>> it? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I do understand the time consuming nature of providing >>>>>>>>>>>>>patches >>>>>>>>>>>>> and merging code. Alena tells me that she has reviewed the >>>>>>>>>>>>>code and she >>>>>>>>>>>>> thinks the design is fine except for this one item. If we >>>>>>>>>>>>>can commit to >>>>>>>>>>>>> fix this problem after the code is checked in, we can check >>>>>>>>>>>>>it in now just >>>>>>>>>>>>> so you don¹t have to do another round of merge and review >>>>>>>>>>>>>for the part that >>>>>>>>>>>>> is working. But the fix will need to be in before the code >>>>>>>>>>>>>is released or >>>>>>>>>>>>> else we might have to revert this checkin. What do you >>>>>>>>>>>>>think? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> P.S. I¹m not sure why this is not on the dev list. We should >>>>>>>>>>>>> bring this back. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.o...@sungardas.com] >>>>>>>>>>>>> *Sent:* Wednesday, May 7, 2014 4:58 PM >>>>>>>>>>>>> *To:* Murali Reddy >>>>>>>>>>>>> *Cc:* Alena Prokharchyk; Alex Huang; Kishan Kavala >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Subject:* Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> All, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alena doesn't want to approve my implementation because of >>>>>>>>>>>>>this >>>>>>>>>>>>> email thread, but I'm frustrated and not sure why this is a >>>>>>>>>>>>>blocker. >>>>>>>>>>>>> >>>>>>>>>>>>> What I did was just created another method without an event >>>>>>>>>>>>>tag >>>>>>>>>>>>> like the one already existing in 'AccountManagerImpl' class >>>>>>>>>>>>>as below. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> @Override >>>>>>>>>>>>> >>>>>>>>>>>>> public boolean enableAccount(long accountId) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> And if we need this feature, we really need to create a new >>>>>>>>>>>>> jira instead of adding it to already existing one >>>>>>>>>>>>> >>>>>>>>>>>>> so that we can discuss options to find a best solution. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It's been a really long path mostly because of >>>>>>>>>>>>> miscommunications, and I really want to wrap this up without >>>>>>>>>>>>>adding a new >>>>>>>>>>>>> feature that is not existing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know what you think. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Alex Ough >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, May 7, 2014 at 10:29 AM, Murali Reddy < >>>>>>>>>>>>> murali.re...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I don¹t think we need to bring back reverted changes, as we >>>>>>>>>>>>> want all the events generated should be published all the >>>>>>>>>>>>>time with in the >>>>>>>>>>>>> region. I agree with Alex Huang, that we could actually add >>>>>>>>>>>>>details >>>>>>>>>>>>> (originating region) to the account indicating source region >>>>>>>>>>>>>where account >>>>>>>>>>>>> is created. Details particular to an event published on the >>>>>>>>>>>>>event bus is a >>>>>>>>>>>>> JSON object so we can add additional details. Also steps >>>>>>>>>>>>>listed out by Alex >>>>>>>>>>>>> should prevent from cyclic propagation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alex Ough, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Suggested steps below by alex should work for you. Do you see >>>>>>>>>>>>> any problem with that? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Murali >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>>>>>> *Date: *Wednesday, 7 May 2014 5:56 AM >>>>>>>>>>>>> *To: *Alex Huang <alex.hu...@citrix.com>, Alex Ough < >>>>>>>>>>>>> alex.o...@sungardas.com>, Kishan Kavala < >>>>>>>>>>>>> kishan.kav...@citrix.com>, Murali Reddy < >>>>>>>>>>>>> murali.re...@citrix.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alex (Huang), thanks for commenting. As a conclusion we >>>>>>>>>>>>> should never omit event firing when submit create/update. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Kishan/Murali, can you please help Alex (Ough) to figure out >>>>>>>>>>>>> how to implement the behavior Kishan reverted. Kishan, can >>>>>>>>>>>>>you check with >>>>>>>>>>>>> Murali how to bring back your reverted changes for the API >>>>>>>>>>>>>to make it work >>>>>>>>>>>>> with the new events framework? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> >>>>>>>>>>>>> Alena. >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Alex Huang <alex.hu...@citrix.com> >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 10:17 AM >>>>>>>>>>>>> *To: *Alena Prokharchyk <alena.prokharc...@citrix.com>, Alex >>>>>>>>>>>>> Ough <alex.o...@sungardas.com> >>>>>>>>>>>>> *Cc: *Kishan Kavala <kishan.kav...@citrix.com> >>>>>>>>>>>>> *Subject: *RE: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hey guys, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I¹m not sure we¹re all on the same page. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> First, the event must always be published, regardless of if >>>>>>>>>>>>>it >>>>>>>>>>>>> was propagated from another region or created originally in >>>>>>>>>>>>>that region. >>>>>>>>>>>>> The reason is there may be other code interested in acting >>>>>>>>>>>>>on account >>>>>>>>>>>>> creation in a region. We just need to provide a way for >>>>>>>>>>>>>Alex¹s code to >>>>>>>>>>>>> determine that the account is propagated rather than created >>>>>>>>>>>>>originally in >>>>>>>>>>>>> the region. You don¹t need details in the event for that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The propagation code can do the following. It¹s probably >>>>>>>>>>>>> already doing that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Listen for the account creation event. >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Upon receiving an account creation event, retrieve >>>>>>>>>>>>> the account to check if the account is propagated or created. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. If propagated, then don¹t propagate or maybe even >>>>>>>>>>>>> signal back that the propagation is done for this region >>>>>>>>>>>>>(depending on the >>>>>>>>>>>>> propagation logic). If created, then propagate to other >>>>>>>>>>>>>regions. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now the detail is in how do we know if an account is created >>>>>>>>>>>>>or >>>>>>>>>>>>> propagated. For that, it can be done in a number of ways. >>>>>>>>>>>>>I¹m open to >>>>>>>>>>>>> which method. I would suggest that we add two fields to >>>>>>>>>>>>>account: >>>>>>>>>>>>> origination region and original uuid. The create account >>>>>>>>>>>>>API takes an >>>>>>>>>>>>> optional fields for the origination region and origination >>>>>>>>>>>>>account uuid. >>>>>>>>>>>>> If these two parameters are not set in the API, the API set >>>>>>>>>>>>>the >>>>>>>>>>>>> origination region to the current region and the original >>>>>>>>>>>>>uuid to the uuid >>>>>>>>>>>>> of the account. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the confusion here. I had thought Kishan added >>>>>>>>>>>>>this >>>>>>>>>>>>> but apparently it has been reverted. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alena Prokharchyk >>>>>>>>>>>>> *Sent:* Tuesday, May 6, 2014 9:57 AM >>>>>>>>>>>>> *To:* Alex Ough >>>>>>>>>>>>> *Cc:* Kishan Kavala; Alex Huang >>>>>>>>>>>>> *Subject:* Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ok, thank you Alex, so looks like there is no other >>>>>>>>>>>>>workaround >>>>>>>>>>>>> as of now rather than introducing the new methods to the >>>>>>>>>>>>>managers. Just go >>>>>>>>>>>>> ahead and submit the rest of the fixes for both review >>>>>>>>>>>>>tickets, and I will >>>>>>>>>>>>> commit the patch after that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -Alena. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Alex Ough <alex.o...@sungardas.com> >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 9:48 AM >>>>>>>>>>>>> *To: *Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>>>>>> *Cc: *Kishan Kavala <kishan.kav...@citrix.com>, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'm afraid it is not possible because the events are set in >>>>>>>>>>>>>the >>>>>>>>>>>>> method level and one of my colleagues implemented to >>>>>>>>>>>>>enable/disable events, >>>>>>>>>>>>> but this is working as globally. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, May 6, 2014 at 12:44 PM, Alena Prokharchyk < >>>>>>>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Kishan, any updates from Murali? All we need to know is if >>>>>>>>>>>>> controlling events possible when command is fired through CS >>>>>>>>>>>>>client APIs >>>>>>>>>>>>> today. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you! >>>>>>>>>>>>> >>>>>>>>>>>>> Alena. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Kishan Kavala <kishan.kav...@citrix.com> >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 7:22 AM >>>>>>>>>>>>> *To: *Alena Prokharchyk <alena.prokharc...@citrix.com> >>>>>>>>>>>>> *Cc: *Alex Ough <alex.o...@sungardas.com>, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alena, >>>>>>>>>>>>> >>>>>>>>>>>>> Events are published using the event framework introduced by >>>>>>>>>>>>> Murali. It can contain additional details to indicate >>>>>>>>>>>>>whether an event >>>>>>>>>>>>> should be propagated to other regions. >>>>>>>>>>>>> >>>>>>>>>>>>> In the implementation I added using API sync, there was a >>>>>>>>>>>>>flag >>>>>>>>>>>>> in the API params to indicate whether to propagate event or >>>>>>>>>>>>>not. I reverted >>>>>>>>>>>>> this code later when we moved to use event framework. >>>>>>>>>>>>> >>>>>>>>>>>>> I'll check with Murali for more details regarding adding >>>>>>>>>>>>> custom details / extending event details. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 06-May-2014, at 4:52 am, "Alena Prokharchyk" < >>>>>>>>>>>>> alena.prokharc...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Alex, I understand that. But if Kishan implemented the way >>>>>>>>>>>>>of >>>>>>>>>>>>> extending the events with the details that can be later on >>>>>>>>>>>>>read by events >>>>>>>>>>>>> recipient, then you should be able to use the API. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If there is no such support, the I agree that the way you do >>>>>>>>>>>>>it >>>>>>>>>>>>> now, is the only one way to achieve the desired >>>>>>>>>>>>>functionality. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -Alena. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From: *Alex Ough <alex.o...@sungardas.com> >>>>>>>>>>>>> *Date: *Monday, May 5, 2014 at 4:08 PM >>>>>>>>>>>>> *To: *Alex Huang <alex.hu...@citrix.com> >>>>>>>>>>>>> *Cc: *Alena Prokharchyk <alena.prokharc...@citrix.com>, >>>>>>>>>>>>>Kishan >>>>>>>>>>>>> Kavala <kishan.kav...@citrix.com> >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region >>>>>>>>>>>>>setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That's exactly why I need methods that do NOT generate events >>>>>>>>>>>>> when the create/update/delete is just for local resources. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, May 5, 2014 at 7:06 PM, Alex Huang < >>>>>>>>>>>>> alex.hu...@citrix.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> That¹s actually what I said. Let me clarify. When Kishan >>>>>>>>>>>>> added the region feature, we discussed the problem of >>>>>>>>>>>>>infinite circular >>>>>>>>>>>>> propagation because each management server that adds an >>>>>>>>>>>>>account will >>>>>>>>>>>>> attempt to propagate it to all the regions by adding it to >>>>>>>>>>>>>that region and >>>>>>>>>>>>> so on. The API needs provide a way for that propagation to >>>>>>>>>>>>>be terminated. >>>>>>>>>>>>> That doesn¹t mean we don¹t publish the event in the region >>>>>>>>>>>>>where the >>>>>>>>>>>>> account is propagated to. We still should publish the event >>>>>>>>>>>>>because that >>>>>>>>>>>>> region did add a new account but the event needs to contain >>>>>>>>>>>>>enough details >>>>>>>>>>>>> for anyone listening to the event to determine that they >>>>>>>>>>>>>should not >>>>>>>>>>>>> propagate the account creation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Alex >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From:* Alena Prokharchyk >>>>>>>>>>>>> *Sent:* Monday, May 5, 2014 2:39 PM >>>>>>>>>>>>> *To:* Kishan Kavala; Alex Ough >>>>>>>>>>>>> *Cc:* Alex Huang >>>>>>>>>>>>> *Subject:* Control event publishing in multi region setups >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Kishan, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Have a question to you. Alex Huang mentioned to me that you >>>>>>>>>>>>> were planning to add support for controlling event >>>>>>>>>>>>>publishing in multi >>>>>>>>>>>>> regions setup. So you can control whether you want to >>>>>>>>>>>>>publish the event in >>>>>>>>>>>>> a particular region when create/update/delete account/domain >>>>>>>>>>>>>API call is >>>>>>>>>>>>> made. Can you please tell us if you¹ve implemented it? And >>>>>>>>>>>>>what parameters >>>>>>>>>>>>> need to be passed to the API call to achieve that. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alex (Ought), if Kishan didn¹t implement this, then I agree >>>>>>>>>>>>> with the way you¹ve added new methods to >>>>>>>>>>>>>Account/DomainManagers to do the >>>>>>>>>>>>> object update w/o the event generation. Lets wait for >>>>>>>>>>>>>Kishan¹s reply. By >>>>>>>>>>>>> now, you can go ahead and fix 1) and 2) in >>>>>>>>>>>>> https://reviews.apache.org/r/20099/ which is not related to >>>>>>>>>>>>> event generation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you! >>>>>>>>>>>>> >>>>>>>>>>>>> -Alena. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
