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