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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
