If you see 'AccountManagerImple', it stores the target resource uuid is stored in the context as below.
CallContext.current().putContextParameter(Account.class, account.getUuid()); So I'd like to store the originated region uuid in the same context so that the event listener can get the originated region uuid along with the target uuid as below. CallContext.current().putContextParameter(Region.class, originatedRegionUuid); On Wed, Jun 4, 2014 at 7:05 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > Alex, > > And are you planning to store regionDetails set on the callContext > anywhere in the DB? So this info can be referred once the call is made > from another context. > > Or your code is going to read it from the memory? In this case, I assume > the follow up code is going to be called within the same context? > > It would be helpful if you explain the process in more details using > regionA/regionB analogy. > > Thanks, > Alena. > > > On 6/4/14, 3:27 PM, "Alex Ough" <alex.o...@sungardas.com> wrote: > > >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. > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>>> > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>>> > >> >> >>>>>>>>>>> > >> >> >>>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>> > >> >> >>>>>> > >> >> >>>>> > >> >> >>>> > >> >> >>> > >> >> >> > >> >> > >> >> > >> >> > >> > >> > >
