Hi Alex Huang, Can you tell me when you're available?
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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
