That information will be updated whenever its resource is changed, so the prior value is not quite meaningful. And as far as I know, there is no synchronization currently working, so all the resources in a region must have been created in the local region.
On Wed, Jun 4, 2014 at 12:36 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > 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. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
