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