Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8D98911B8C for ; Wed, 4 Jun 2014 16:43:05 +0000 (UTC) Received: (qmail 58753 invoked by uid 500); 4 Jun 2014 16:43:04 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 58717 invoked by uid 500); 4 Jun 2014 16:43:04 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 58707 invoked by uid 99); 4 Jun 2014 16:43:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 16:43:04 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [74.125.149.141] (HELO na3sys009aog128.obsmtp.com) (74.125.149.141) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jun 2014 16:42:56 +0000 Received: from mail-la0-f45.google.com ([209.85.215.45]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKU49MdWz4F+mIch4nxp2RTbkS/rSa3mcm@postini.com; Wed, 04 Jun 2014 09:42:30 PDT Received: by mail-la0-f45.google.com with SMTP id s18so2620218lam.32 for ; Wed, 04 Jun 2014 09:42:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K/a4aVqJMAPuOooX6Y/VMKFm6hVzQK0iro36mWsk+5k=; b=mdpTK5YoLXo1Az62SdiUp95Ww+Rdw/cR7Q7RVmzN4rpz4vz89zdWHaX6YYvKj9ptpJ gSMfiN1kRsr+oa2czclOfEhOkY1iq9CtrPcVMfYHPzw0v4YIlKLnEITiprQqkf8FSha0 hItLPViOD0uB+wv+n1m0WKuCKnRaiU+PpnkP3u/XZ384oIPOx+SCtJkEfGhbYYW7mOXj UqfF4wMwZZzcU9ceyQh/vNq4Hexz2uxUntGuiDvhePqvZF5x4nzr0DS0dfhrAspIKnTe uEW8unyvWdwGYJco+X23WVhTmVRULOTgeRnupKtzANe1Y1Dshg/t0WsjDviEi+JRFzKT RJQA== X-Gm-Message-State: ALoCoQmNq2hTHfAnUYhIPrEdx5G2+bely7TJvxjoKh6bET4ixagcdv+NAUQi8W2BuUPduQrZJKyYmQvc4DvbOjsWuC+C8cNjcpEfiW7jratwGV99YN5bYvfH596eZHCAhFhXaXRJnfO/ X-Received: by 10.112.51.37 with SMTP id h5mr31281125lbo.24.1401900147631; Wed, 04 Jun 2014 09:42:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.51.37 with SMTP id h5mr31281114lbo.24.1401900147504; Wed, 04 Jun 2014 09:42:27 -0700 (PDT) Received: by 10.112.215.229 with HTTP; Wed, 4 Jun 2014 09:42:27 -0700 (PDT) In-Reply-To: References: <20CF38CB4385CE4D9D1558D52A0FC05870BD1D@SJCPEX01CL03.citrite.net> <20CF38CB4385CE4D9D1558D52A0FC05870BE09@SJCPEX01CL03.citrite.net> <20CF38CB4385CE4D9D1558D52A0FC05870CB2D@SJCPEX01CL03.citrite.net> <20CF38CB4385CE4D9D1558D52A0FC05870CCA4@SJCPEX01CL03.citrite.net> Date: Wed, 4 Jun 2014 12:42:27 -0400 Message-ID: Subject: Re: Control event publishing in multi region setups From: Alex Ough To: "dev@cloudstack.apache.org" Cc: Alex Huang , Murali Reddy , Kishan Kavala Content-Type: multipart/alternative; boundary=001a1133b16e4d8eda04fb055062 X-Virus-Checked: Checked by ClamAV on apache.org --001a1133b16e4d8eda04fb055062 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That information will be updated whenever its resource is changed, so the prior value is not quite meaningful. 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. On Wed, Jun 4, 2014 at 12:36 PM, Alena Prokharchyk < Alena.Prokharchyk@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=C2=B9s DB. > > -Alena. > > On 6/4/14, 9:33 AM, "Alex Ough" 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.Prokharchyk@citrix.com> wrote: > > > >> Alex, one more bullet is needed. > >> > >> #5 During the DB upgrade all the account/domain/user records should b= e > >> populated with =C2=B3originated_region_uuid=C2=B2 =3D one of the regio= ns in the > >>system. > >> The region should be picked using =C2=B3region having smallest UUID=C2= =B2 > >>criteria. > >> > >> -alena. > >> > >> From: Alex Ough > >> Date: Wednesday, June 4, 2014 at 5:28 AM > >> > >> To: Alena Prokharchyk > >> Cc: Alex Huang , Murali Reddy < > >> Murali.Reddy@citrix.com>, Kishan Kavala , " > >> 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 a= nd > >> they will be populated with the current local region uuid when the > >>fields > >> are created during the schema changes because we can guarantee that th= e > >> 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.Prokharchyk@citrix.com> wrote: > >> > >>> Yes, I=C2=B9m 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 > >>> Date: Monday, June 2, 2014 at 9:49 AM > >>> > >>> To: Alena Prokharchyk > >>> Cc: Alex Huang , Murali Reddy < > >>> Murali.Reddy@citrix.com>, Kishan Kavala , " > >>> 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 > >>> 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.Prokharchyk@citrix.com> wrote: > >>>> > >>>>> Alex, I=C2=B9m on vacation tomorrow; leaving today at 2 pm. > >>>>> > >>>>> Thanks, > >>>>> Alena. > >>>>> > >>>>> From: Alex Ough > >>>>> Date: Wednesday, May 14, 2014 at 1:18 PM > >>>>> > >>>>> To: Alena Prokharchyk > >>>>> Cc: Alex Huang , Murali Reddy < > >>>>> Murali.Reddy@citrix.com>, Kishan Kavala , > " > >>>>> 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 > >>>>> 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.Prokharchyk@citrix.com> wrote: > >>>>>> > >>>>>>> Alex, sure we can have a call. I=C2=B9m in the office till 2 pm = PST > >>>>>>> today. Send the meeting invitation to me and Alex. > >>>>>>> > >>>>>>> From: Alex Ough > >>>>>>> Date: Wednesday, May 14, 2014 at 11:33 AM > >>>>>>> > >>>>>>> To: Alena Prokharchyk > >>>>>>> Cc: Alex Huang , Murali Reddy < > >>>>>>> Murali.Reddy@citrix.com>, Kishan Kavala > >>>>>>>, " > >>>>>>> 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 wi= th > >>>>>>> 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 > >>>>>>> > >>>>>>> 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.Prokharchyk@citrix.com> wrote: > >>>>>>>> > >>>>>>>>> Alex, we do understand how =C2=B3Full Scan=C2=B2 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 =C2=B3Local=C2=B2 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/servic= e > >>>>>>>>>needs. The > >>>>>>>>> same applies to introducing another method w/o event generation= . > >>>>>>>>> Both > >>>>>>>>> solutions are incorrect, and I=C2=B9m against putting them to t= he 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 =C2=AD object id/uuid/status. If we let third party > >>>>>>>>>components to > >>>>>>>>> enhance the events, they would grow exponentially and certai= n > >>>>>>>>>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 th= e > >>>>>>>>>subscribers. > >>>>>>>>> 3. If subscriber needs to get more details about the object = =C2=AD > >>>>>>>>> account/domain/user =C2=AD 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 =C2=AD which region. > >>>>>>>>> > >>>>>>>>> So the solution for your plugin would be as Alex Huang suggeste= d > >>>>>>>>> originally =C2=AD 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= =C2=B9m > >>>>>>>>>open to > >>>>>>>>> which method. I would suggest that we add two fields to accoun= t: > >>>>>>>>> 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 th= e > >>>>>>>>> origination region to the current region and the original uuid > >>>>>>>>>to the uuid > >>>>>>>>> of the account. " > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Alena. > >>>>>>>>> > >>>>>>>>> From: Alex Ough > >>>>>>>>> Date: Wednesday, May 14, 2014 at 6:44 AM > >>>>>>>>> To: Alena Prokharchyk > >>>>>>>>> > >>>>>>>>> Cc: Alex Huang , Murali Reddy < > >>>>>>>>> Murali.Reddy@citrix.com>, Kishan Kavala > >>>>>>>>>, > >>>>>>>>> "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 wor= k > >>>>>>>>> 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 need= s > >>>>>>>>>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 t= o > >>>>>>>>> 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.Prokharchyk@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 > >>>>>>>>>> =C2=AD your local region =C2=AD doesn=C2=B9t need this data, b= ut you can=C2=B9t > >>>>>>>>>>make this call > >>>>>>>>>> on behalf of everybody else. Example of the possible scenario: > >>>>>>>>>>somebody > >>>>>>>>>> wants to perform user=C2=B9s update once corresponding account= gets > >>>>>>>>>>updated, > >>>>>>>>>> within the same region. And they rely on in-memory bus to catc= h > >>>>>>>>>> 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 decisio= n > >>>>>>>>>>whether to > >>>>>>>>>> ignore the event, or process it further. Alex proposed to > >>>>>>>>>>enhance the > >>>>>>>>>> account/domain/user object with the field identifying who=C2= =B9s > >>>>>>>>>>triggered the > >>>>>>>>>> upgrade to give more details to the recipient. > >>>>>>>>>> > >>>>>>>>>> -Alena. > >>>>>>>>>> > >>>>>>>>>> From: Alex Ough > >>>>>>>>>> Date: Monday, May 12, 2014 at 6:14 PM > >>>>>>>>>> > >>>>>>>>>> To: Alena Prokharchyk > >>>>>>>>>> Cc: Alex Huang , Murali Reddy < > >>>>>>>>>> Murali.Reddy@citrix.com>, Kishan Kavala > >>>>>>>>>>, > >>>>>>>>>> "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 yo= u > >>>>>>>>>> want to send data that is absolutely useless to the destinatio= n? > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> Alex Ough > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Mon, May 12, 2014 at 6:19 PM, Alena Prokharchyk < > >>>>>>>>>> Alena.Prokharchyk@citrix.com> wrote: > >>>>>>>>>> > >>>>>>>>>>> Alex, I can=C2=B9t approve the current approach you use in y= our > >>>>>>>>>>>fix. > >>>>>>>>>>> The reason that there are bugs in the current CS code, and > >>>>>>>>>>>therefore we can > >>>>>>>>>>> contribute more to the buggy behavior, doesn=C2=B9t sound rig= ht to > >>>>>>>>>>>me. And we > >>>>>>>>>>> have =C2=AD1 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=C2=B9m > >>>>>>>>>>> back. > >>>>>>>>>>> > >>>>>>>>>>> -Alena. > >>>>>>>>>>> > >>>>>>>>>>> From: Alex Ough > >>>>>>>>>>> Date: Monday, May 12, 2014 at 3:13 PM > >>>>>>>>>>> To: Alena Prokharchyk > >>>>>>>>>>> Cc: Alex Huang , Murali Reddy < > >>>>>>>>>>> Murali.Reddy@citrix.com>, Kishan Kavala > >>>>>>>>>>>, > >>>>>>>>>>> "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 afte= r > >>>>>>>>>>> our conversation without consulting with Alex Hwang. > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> Alex Ough > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Mon, May 12, 2014 at 2:37 PM, Alena Prokharchyk < > >>>>>>>>>>> Alena.Prokharchyk@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=C2=B9m going to be on vacation from May 15th= till > >>>>>>>>>>>> May 31st, if you and Alex(Huang) have your > >>>>>>>>>>>>discussion/resolution while I=C2=B9m > >>>>>>>>>>>> away, I can commit the patches only after I=C2=B9m back. > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you! > >>>>>>>>>>>> Alena. > >>>>>>>>>>>> > >>>>>>>>>>>> From: Alex Ough > >>>>>>>>>>>> Date: Sunday, May 11, 2014 at 10:10 PM > >>>>>>>>>>>> To: Alex Huang > >>>>>>>>>>>> Cc: Murali Reddy , Alena Prokharchy= k > >>>>>>>>>>>>< > >>>>>>>>>>>> alena.prokharchyk@citrix.com>, Kishan Kavala < > >>>>>>>>>>>> Kishan.Kavala@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.Huang@citrix.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Alex and Alena, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Perhaps, it=C2=B9s best you two get on the phone about this= . I > >>>>>>>>>>>>> don=C2=B9t see Alex understanding what I=C2=B9m saying over= email so > >>>>>>>>>>>>>there=C2=B9s no point > >>>>>>>>>>>>> in me repeating it. I=C2=B9m not around next week and I th= ink > >>>>>>>>>>>>>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.ough@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 th= e > >>>>>>>>>>>>> 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.ough@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.Huang@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> -1 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I do not believe in the argument that says =C2=B3since ther= e=C2=B9s > >>>>>>>>>>>>> existing bad code, then I can check in code that also cause= s > >>>>>>>>>>>>>regressions > >>>>>>>>>>>>> for users.=C2=B2 If that=C2=B9s the case, what=C2=B9s the = point of the > >>>>>>>>>>>>>review? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> We=C2=B9ve offered a path forward already. Please reconsid= er > >>>>>>>>>>>>>that. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> --Alex > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.ough@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.ough@sungardas.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> That's why there are 2 methods, one is that generates even= ts > >>>>>>>>>>>>> and the other not and there are already a few public method= s > >>>>>>>>>>>>>without event > >>>>>>>>>>>>> decoration. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, May 8, 2014 at 2:25 PM, Alex Huang < > >>>>>>>>>>>>> Alex.Huang@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alex, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I did read this when you first proposed. I do understand t= he > >>>>>>>>>>>>> two implementation. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I understand that #2 is not activated via events but it > >>>>>>>>>>>>>doesn=C2=B9t > >>>>>>>>>>>>> mean #2 can just don=C2=B9t generate events. The blocker i= s > >>>>>>>>>>>>>precisely with the > >>>>>>>>>>>>> last sentence in #2 where it states #2 doesn=C2=B9t generat= e an > >>>>>>>>>>>>>event when =C2=B3it > >>>>>>>>>>>>> creates/updates/removes the resource in the local region=C2= =B2. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 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=C2=B9t 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.ough@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 an= d > >>>>>>>>>>>>>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.Huang@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Alex, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please know that the contribution is much appreciated. It = is > >>>>>>>>>>>>> not a case of whether or not Alena =C2=B3wants=C2=B2 or =C2= =B3doesn=C2=B9t want=C2=B2 > >>>>>>>>>>>>>to approve the > >>>>>>>>>>>>> review. She can only approve if the design is sound and ha= s > >>>>>>>>>>>>>no regression > >>>>>>>>>>>>> for existing deployments of CloudStack. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> This is a blocker because not publishing events when an > >>>>>>>>>>>>>account > >>>>>>>>>>>>> is propagated is actually an =C2=B3incorrect=C2=B2 behavior= for > >>>>>>>>>>>>>CloudStack. Any > >>>>>>>>>>>>> functionality that acts on an account creation within the > >>>>>>>>>>>>>region will face > >>>>>>>>>>>>> regression. That=C2=B9s why it is not =C2=B3an additional = feature=C2=B2 > >>>>>>>>>>>>>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=C2=B9t generate > >>>>>>>>>>>>> the event consistently, would it not consider this a bug an= d > >>>>>>>>>>>>>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=C2=B9t have to do another round of merge and rev= iew > >>>>>>>>>>>>>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=C2=B9m not sure why this is not on the dev list. We= should > >>>>>>>>>>>>> bring this back. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From:* Alex Ough [mailto:alex.ough@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 withou= t > >>>>>>>>>>>>>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.Reddy@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> I don=C2=B9t 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 regio= n > >>>>>>>>>>>>>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 s= ee > >>>>>>>>>>>>> any problem with that? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Murali > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From: *Alena Prokharchyk > >>>>>>>>>>>>> *Date: *Wednesday, 7 May 2014 5:56 AM > >>>>>>>>>>>>> *To: *Alex Huang , Alex Ough < > >>>>>>>>>>>>> alex.ough@sungardas.com>, Kishan Kavala < > >>>>>>>>>>>>> Kishan.Kavala@citrix.com>, Murali Reddy < > >>>>>>>>>>>>> murali.reddy@citrix.com> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region > >>>>>>>>>>>>>setups > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alex (Huang), thanks for commenting. As a conclusion =C2= =AD we > >>>>>>>>>>>>> should never omit event firing when submit create/update. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Kishan/Murali, can you please help Alex (Ough) to figure ou= t > >>>>>>>>>>>>> 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 > >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 10:17 AM > >>>>>>>>>>>>> *To: *Alena Prokharchyk , Ale= x > >>>>>>>>>>>>> Ough > >>>>>>>>>>>>> *Cc: *Kishan Kavala > >>>>>>>>>>>>> *Subject: *RE: Control event publishing in multi region > >>>>>>>>>>>>>setups > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hey guys, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I=C2=B9m not sure we=C2=B9re 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=C2=B9s code to > >>>>>>>>>>>>> determine that the account is propagated rather than create= d > >>>>>>>>>>>>>originally in > >>>>>>>>>>>>> the region. You don=C2=B9t need details in the event for t= hat. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> The propagation code can do the following. It=C2=B9s proba= bly > >>>>>>>>>>>>> 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 create= d. > >>>>>>>>>>>>> > >>>>>>>>>>>>> 3. If propagated, then don=C2=B9t 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 create= d > >>>>>>>>>>>>>or > >>>>>>>>>>>>> propagated. For that, it can be done in a number of ways. > >>>>>>>>>>>>>I=C2=B9m 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 se= t > >>>>>>>>>>>>>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 > >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 9:48 AM > >>>>>>>>>>>>> *To: *Alena Prokharchyk > >>>>>>>>>>>>> *Cc: *Kishan Kavala , Alex Huang = < > >>>>>>>>>>>>> Alex.Huang@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.Prokharchyk@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Kishan, any updates from Murali? All we need to know is = =C2=AD if > >>>>>>>>>>>>> controlling events possible when command is fired through C= S > >>>>>>>>>>>>>client APIs > >>>>>>>>>>>>> today. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you! > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alena. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From: *Kishan Kavala > >>>>>>>>>>>>> *Date: *Tuesday, May 6, 2014 at 7:22 AM > >>>>>>>>>>>>> *To: *Alena Prokharchyk > >>>>>>>>>>>>> *Cc: *Alex Ough , Alex Huang < > >>>>>>>>>>>>> Alex.Huang@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.Prokharchyk@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 d= o > >>>>>>>>>>>>>it > >>>>>>>>>>>>> now, is the only one way to achieve the desired > >>>>>>>>>>>>>functionality. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -Alena. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> *From: *Alex Ough > >>>>>>>>>>>>> *Date: *Monday, May 5, 2014 at 4:08 PM > >>>>>>>>>>>>> *To: *Alex Huang > >>>>>>>>>>>>> *Cc: *Alena Prokharchyk , > >>>>>>>>>>>>>Kishan > >>>>>>>>>>>>> Kavala > >>>>>>>>>>>>> *Subject: *Re: Control event publishing in multi region > >>>>>>>>>>>>>setups > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> That's exactly why I need methods that do NOT generate even= ts > >>>>>>>>>>>>> when the create/update/delete is just for local resources. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, May 5, 2014 at 7:06 PM, Alex Huang < > >>>>>>>>>>>>> Alex.Huang@citrix.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> That=C2=B9s actually what I said. Let me clarify. When K= ishan > >>>>>>>>>>>>> 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=C2=B9t mean we don=C2=B9t publish the event in = the region > >>>>>>>>>>>>>where the > >>>>>>>>>>>>> account is propagated to. We still should publish the even= t > >>>>>>>>>>>>>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/domai= n > >>>>>>>>>>>>>API call is > >>>>>>>>>>>>> made. Can you please tell us if you=C2=B9ve implemented it?= And > >>>>>>>>>>>>>what parameters > >>>>>>>>>>>>> need to be passed to the API call to achieve that. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Alex (Ought), if Kishan didn=C2=B9t implement this, then I = agree > >>>>>>>>>>>>> with the way you=C2=B9ve added new methods to > >>>>>>>>>>>>>Account/DomainManagers to do the > >>>>>>>>>>>>> object update w/o the event generation. Lets wait for > >>>>>>>>>>>>>Kishan=C2=B9s 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. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > --001a1133b16e4d8eda04fb055062--