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