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 3F0C7110DE for ; Thu, 26 Jun 2014 01:34:27 +0000 (UTC) Received: (qmail 73583 invoked by uid 500); 26 Jun 2014 01:34:26 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 73538 invoked by uid 500); 26 Jun 2014 01:34:26 -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 73526 invoked by uid 99); 26 Jun 2014 01:34:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2014 01:34:26 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_NEUTRAL,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.149.145] (HELO na3sys009aog121.obsmtp.com) (74.125.149.145) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2014 01:34:21 +0000 Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKU6t4gaouc271M1kXYr3SOC4w+ACik2J2@postini.com; Wed, 25 Jun 2014 18:33:55 PDT Received: by mail-la0-f52.google.com with SMTP id ty20so1335942lab.39 for ; Wed, 25 Jun 2014 18:33:52 -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=q0nHg8ZE80xDa22K2UmQYQr4d+u0LlufYhEI2Zoq+oM=; b=OdOAsZC5n3VwW10MKk4Hv6mwmQvr5VDtcFs/KgPl1nwJPJPrPpAVfpTLMNW3Qeteut 7Jq6kFiKM6Wu+Uz/qMgnzLclyhTdJKjueEqgLb5ysmNaLLQKeijVoPIGqYamiU5mDzwk WRN6usLrZW7DLTKfSosmf6ea3CWGWBr0QbJfbA7wMssj3XVVLnPqigr+8WhKaYS/D/3n LiRUlLyfLGBPKW2WnifS8KhlEqCBQ+m0Ul/QYhIjk2lJHdXRgICGjjkMPezg0xgjQ/4k jeM9UZlPpt2QU9Qkp8zYN8Oet/blG7ibg3ZlIDuN1Frx5+6B68aQoJBtDQS7CTK98AoT dm6w== X-Gm-Message-State: ALoCoQm2AbLE6790VaV+nfDaYiUFVz2duX5/6hsUiA6sK49roFmh3tXnRQccDQmzKU5p3vgWhfNjpkn4p4bO7jbye+IzYsSFkptf/K1+cVzKF2YsWH77oRBQ9VlC9+8FvYnV4yKNWRmm X-Received: by 10.152.5.230 with SMTP id v6mr8442699lav.33.1403746432185; Wed, 25 Jun 2014 18:33:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.5.230 with SMTP id v6mr8442678lav.33.1403746431915; Wed, 25 Jun 2014 18:33:51 -0700 (PDT) Received: by 10.112.215.229 with HTTP; Wed, 25 Jun 2014 18:33:51 -0700 (PDT) In-Reply-To: References: <20140624155416.22603.25946@reviews.apache.org> <20140624181236.22595.23668@reviews.apache.org> Date: Wed, 25 Jun 2014 21:33:51 -0400 Message-ID: Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes) From: Alex Ough To: Alena Prokharchyk Cc: Kishan Kavala , "dev@cloudstack.apache.org" , Murali Reddy , Ram Ganesh , Animesh Chaturvedi Content-Type: multipart/alternative; boundary=089e0149333e6dec0b04fcb32fd0 X-Virus-Checked: Checked by ClamAV on apache.org --089e0149333e6dec0b04fcb32fd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Alena, and I'm glad if they spend time for the review, but could it be a little earlier for you to ask them to review instead of at the last moment? I'm really exhausted with repeatedly added items whenever I post a review. Thanks Alex Ough On Wed, Jun 25, 2014 at 7:44 PM, Alena Prokharchyk < Alena.Prokharchyk@citrix.com> wrote: > Alex, looks fine to me. Make sure that you put the regionId validation > as our in-built API validation won=E2=80=99t work in this case because th= ere is no > UUID field support for the Region object. You can check how validation is > begin done in updateRegion/deleteRegion scenarios. > > Kishan/Murali, can you please spend some time doing the final review for > Alex=E2=80=99s tickets? As you are the original developers for Region, an= d probably > have the most expertise on the topic. I don=E2=80=99t want to commit the = fixes > before I hear =E2=80=9Cship it=E2=80=9D from both of you, guys. > > Thanks, > Alena. > From: Alex Ough > Date: Wednesday, June 25, 2014 at 4:02 PM > To: Kishan Kavala > Cc: Alena Prokharchyk , " > dev@cloudstack.apache.org" , Murali Reddy < > Murali.Reddy@citrix.com>, Ram Ganesh , Animesh > Chaturvedi > > Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among > Multiple Regions (Core Changes) > > Hi Alena, > > Can you confirm if this fix is correct? > > @Parameter(name =3D ApiConstants.ORIGINATED_REGION_ID, type =3D > CommandType.INTEGER, description =3D "Region where this account is create= d.", > since =3D "4.5") > private Integer originatedRegionId; > > Thanks > Alex Ough > > > On Wed, Jun 25, 2014 at 11:03 AM, Kishan Kavala > wrote: > >> Alex, >> >> You can refer to the code from initDataSource method in >> Transaction.java. >> >> Properties file can be loaded using the following: >> >> >> >> *File dbPropsFile =3D PropertiesUtil.findConfigFile(propsFileName);* >> >> >> >> *From:* Alex Ough [mailto:alex.ough@sungardas.com] >> *Sent:* Wednesday, 25 June 2014 4:31 PM >> *To:* Kishan Kavala >> *Cc:* Alena Prokharchyk; dev@cloudstack.apache.org; Murali Reddy; Ram >> Ganesh; Animesh Chaturvedi >> >> *Subject:* Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> Thanks Kishan, but there seems to be lots of 'db.properties' files, so >> which one should be referenced? >> >> >> >> Alex Ough >> >> >> >> On Wed, Jun 25, 2014 at 2:25 AM, Kishan Kavala >> wrote: >> >> Alex, >> >> As Alena mentioned, it is admin=E2=80=99s responsibility to keep ids sam= e across >> Regions. Ids should be used as unique identifier. Region name is merely >> descriptive name and its mostly associated with geographic location. >> >> Also note that region name can be updated anytime using updateRegion API= . >> >> >> >> Unlike, other internal Ids in CS, region Ids are assigned by admin. So >> exposing region Id to admin should not be an issue. >> >> >> >> Id of the local region cannot be guaranteed to be =E2=80=9C1=E2=80=9D al= ways. Region Id >> has to be unique across all regions. While creating new region admin wil= l >> provide unique region id to *cloud-setup-databases* script. Id of the >> local region is stored in db.properties. To identify a Local region you = can >> use one of the following options: >> >> 1. Look up region.id in db.properties >> >> 2. Add a new column in region table >> >> >> >> >> >> *From:* Alex Ough [mailto:alex.ough@sungardas.com] >> *Sent:* Wednesday, 25 June 2014 8:18 AM >> *To:* Alena Prokharchyk >> *Cc:* dev@cloudstack.apache.org; Kishan Kavala; Murali Reddy; Ram >> Ganesh; Animesh Chaturvedi >> >> >> *Subject:* Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> There is one thing that was not mentioned, which is that currently the i= d >> of 'Local' region is always 1 and if we do not guarantee that, there is = no >> way to find out which is the local region unless we add one more field t= o >> tells which is the local region. >> >> I'm wondering if we have a solution for this now. >> >> >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 9:59 PM, Alex Ough >> wrote: >> >> I agree with that the ids are unique identifier, but they are usually >> internal purpose not exposed to the users. So it is a little strange to = ask >> users to assign ids when they add new regions. And if we do not allow >> duplicated names, I'm not sure why it is not good to use names as a uniq= ue >> identifier. >> >> >> >> It's been a long way to come this far with several reasons, so I really >> want to wrap this up as soon as possible, and this doesn't seem to be a >> major obstacle, so let me just use 'id' as a parameter if there is no on= e >> with a different thought until tomorrow morning. >> >> >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 8:52 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> Alex, id is used as a unique identifier for CS objects. And it is the CS >> requirement to refer to the object by id if the id is present. Look at a= ll >> the other APIs. We nowhere refer to the network/vpc/vm by name just beca= use >> its more human readable. The id is used by Api layer when parameter >> validation is done, by lots of Dao methods (findById is one of them), et= c. >> Even look at updateRegion/deleteRegion =E2=80=93 we don=E2=80=99t refer= to them by name, >> but by the id. >> >> >> >> The reason why Kishan added the support for controlling the id by adding >> it to the createRegion call (and making it unique) is exactly that =E2= =80=93 region >> administrator can decide what id to set on the region, and to introduce = the >> region with the same id to the other regions=E2=80=99 db. >> >> >> >> So I would still suggest on using the id of the region in the API calls >> you are modifying. Unless developers who worked on regions feature =E2= =80=93 >> Kishan/Murali =E2=80=93 come up with the valid objection. >> >> >> >> Thanks, >> >> Alena. >> >> >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 5:41 PM >> >> >> *To: *Alena Prokharchyk >> *Cc: *"dev@cloudstack.apache.org" , Kishan >> Kavala , Murali Reddy , >> Ram Ganesh , Animesh Chaturvedi < >> animesh.chaturvedi@citrix.com> >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> We can use the same ids & names, but we don't have to use the same ids i= f >> we use names, which is a little easier because names are user readable b= ut >> ids are not, so we don't need to memorize/check all the ids when we add = new >> regions in multiple regions, which can be confusing. >> >> >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 8:33 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> Aren=E2=80=99t we supposed to sync the regions across the multiple regio= ns Dbs? >> Because that=E2=80=99s what region FS states: >> >> >> >> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/AWS-Style+Regions= +Functional+Spec, >> =E2=80=9CAdding 2nd region=E2=80=9D paragraph, bullet #4: >> >> >> >> 1. Install a 2nd CS instance. >> >> 2. While installing database set region_id using -r option in >> cloud-setup-databases script (Make sure *database_key* is same across >> all regions). >> >> *cloud-setup-databases cloud:**<**dbpassword**>**@localhost >> --deploy-as=3Droot:**<**password**>** -e **<**encryption_type**>** -m **= <* >> *management_server_key**>** -k **<**database_key**> -r * >> >> 3. Start mgmt server >> >> 4. *Using addRegion API, add region 1 to region 2 and also region 2 to >> region 1.* >> >> >> >> I assume that we expect the admin to add the region with the same name >> and the same id to ALL regions Dbs (both id and name should be passed to >> createRegion call). So they are all in sync. Isn=E2=80=99t it the requir= ement? If >> so, we should rely on the fact that all regions Dbs will have the same s= et >> of regions having the same ids and names cross regions. >> >> >> >> Thanks, >> >> Alena. >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 5:17 PM >> *To: *Alena Prokharchyk >> *Cc: *"dev@cloudstack.apache.org" , Kishan >> Kavala , Murali Reddy , >> Ram Ganesh , Animesh Chaturvedi < >> animesh.chaturvedi@citrix.com> >> >> >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> What I'm trying to say is that when we pass the ids of regions, the >> receivers do not know what the originated region is and the id of each >> region is not same across all the regions. >> >> >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 7:35 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> Alex, thank you for summarizing. >> >> >> >> I still don=E2=80=99t see why id can=E2=80=99t be unique across regions= as you can >> control the id assignment =E2=80=93 id is required when createRegion cal= l is made. >> And that=E2=80=99s how the region should be represented in other region= =E2=80=99s Dbs =E2=80=93 by >> its id that is unique across the regions. Kishan/Murali, please confirm. >> >> >> >> Thank you, >> >> Alena. >> >> >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 4:22 PM >> *To: *"dev@cloudstack.apache.org" >> *Cc: *Alena Prokharchyk , Kishan Kavala < >> Kishan.Kavala@citrix.com>, Murali Reddy , Ram >> Ganesh , Animesh Chaturvedi < >> animesh.chaturvedi@citrix.com> >> >> >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> All, >> >> >> >> There is one open question in this topic, which is to figure out which >> value is appropriate to pass the region object, id or name? >> >> During this implementation, we decided to add the information of regions >> where user/account/domain objects have been originally >> created/modified/removed. >> >> But the ids of regions are not same across the regions and currently the >> regions do not have uuids(they will not be same either if we add them to >> regions), so I'd like to use names. >> >> >> >> Please let me know what you think. >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 7:05 PM, Animesh Chaturvedi < >> animesh.chaturvedi@citrix.com> wrote: >> >> Let=E2=80=99s have the discussion on dev mailing list >> >> >> >> Thanks >> >> Animesh >> >> >> >> *From:* Alena Prokharchyk >> *Sent:* Tuesday, June 24, 2014 3:06 PM >> *To:* Alex Ough; Kishan Kavala; Murali Reddy >> *Cc:* Animesh Chaturvedi; Ram Ganesh >> >> >> *Subject:* Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> Adding Kishan to the thread as he was the one who implemented the region >> feature originally. >> >> >> >> Kishan, in a situation when there are 2 regions in the system, we expect >> =E2=80=9Cregion=E2=80=9D table to be populated with the same id/name in = both Dbs for both >> regions, right? So my question is =E2=80=93 what uniquely identifies the= region in >> CS system in cross region setup =E2=80=93 id/name? >> >> >> >> That unique identifier should be the value that is passed to the calls >> you modify, Alex. WE can=E2=80=99t just pass some random name to the cal= l without >> making any further verification. >> >> >> >> Kishan/Murali, please help to verify this part of Alex=E2=80=99s fix as = it should >> really be someone with an expertise in Regions. I=E2=80=99ve reviewed th= e rest of >> the feature, just this one item is open. See my latest comment to the >> https://reviews.apache.org/r/17790/diff/?page=3D1#0 as well as refer to >> this email thread for the context. >> >> >> >> -Alena. >> >> >> >> *From: *Alena Prokharchyk >> *Date: *Tuesday, June 24, 2014 at 2:54 PM >> *To: *Alex Ough >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> That what would everybody assume 100% just by looking at the parameter >> description and parameter =E2=80=93 that you refer to region UUID : "Reg= ion where >> this account is created.=E2=80=9D/ORIGINATEDREGIONUUID >> >> In CS the UUID has a special meaning. It has to have the UUID format, an= d >> its randomly generated value that is stored in the DB along with the act= ual >> db id. I can see that regionVO lacks UUID field. Looks like existing >> RegionVO object lacks this filed unlike other CS objects (uservm, etc). = I >> will follow up with Murali on that. >> >> >> >> Alex, so originatedRegionUUID refers to the region name, correct?. Why >> don=E2=80=99t use the region id instead? That=E2=80=99s what we do when = refer to CS objects >> =E2=80=93 we always refer to them by id which is unique. Which is true e= ven for the >> region: >> >> >> >> mysql> show create table region; >> >> >> >> UNIQUE KEY `id` (`id`), >> >> UNIQUE KEY `name` (`name`) >> >> >> >> >> >> That=E2=80=99s what you do when you manipulate the region itself >> (delete/updateRegion) - refer to the region by its id. And this field is >> returned to you when you call listRegions API: >> >> >> >> http://localhost:8096/?command=3DlistRegions >> >> >> >> 1 >> >> Local >> >> http://localhost:8080/client/ >> >> true >> >> false >> >> >> >> >> >> >> >> Please correct if I miss something. >> >> -Alena. >> >> >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 2:33 PM >> *To: *Alena Prokharchyk >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> Thanks for the clarification, but here is a thing. >> >> >> >> I'm passing names as the values of originatedRegionUuids because the >> uuids are randomly generated and the same regions do NOT have the same >> uuidss. >> >> So I'd like to change the parameter types into String. >> >> Let me know if you think otherwise. >> >> >> >> Thanks >> >> Alex Ough >> >> >> >> On Tue, Jun 24, 2014 at 5:17 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> Alex, >> >> >> >> take a look at ParamProcessWorker class, and how API parameters are bein= g >> dispatched/verified. >> >> >> >> >> >> 1) public void processParameters(final BaseCmd cmd, final Map params) >> method >> >> >> >> First of all, EntityType parameter should be defined in the @Parameter >> annotation for the originatedRegionID field. This parameter is used by >> paramProcessWorker to make "if entity exists" validation >> >> >> >> >> >> 2) Check another method in the same class: >> >> >> >> private void setFieldValue(final Field field, final BaseCmd cmdObj, fina= l >> Object paramObj, final Parameter annotation) throws >> IllegalArgumentException, ParseException { >> >> >> >> Thats the method responsible for dispatching/setting the field values. >> Here is the snippet of the code for the case when UUID is defined: >> >> >> >> case UUID: >> >> if (paramObj.toString().isEmpty()) >> >> break; >> >> final Long internalId =3D >> translateUuidToInternalId(paramObj.toString(), annotation); >> >> field.set(cmdObj, internalId); >> >> break; >> >> >> >> it always transforms the UUID to Long id, not string. And at the end, it >> will be internal DB UUID, not the UUID. If you need the UUID, you have t= o >> get it by a) retrieving the object from the DB by id b) Getting its UUID >> property. >> >> >> >> If you leave it as a String, you will hit IllegalArgumentException at >> "field.set(cmdObj, internalId);" line. >> >> >> >> >> >> Hope it answers your questions, and let me know if anything else needs t= o >> be clarified. >> >> >> >> -alena. >> >> >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 1:57 PM >> >> >> *To: *Alena Prokharchyk >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> Why do you want to change UUID to 'Long'? >> >> Can you just correct what I fixed? >> >> >> >> On Tue, Jun 24, 2014 at 4:21 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> You need to put: >> >> >> >> * the entityType parameter to the annotation. >> >> - Change the type to Long as I=E2=80=99ve already mentioned. Check ho= w other >> commands handle the parameters (networkId, vpcId, etc) >> >> =E2=80=94Alena. >> >> >> >> *From: *Alex Ough >> *Date: *Tuesday, June 24, 2014 at 12:47 PM >> >> >> *To: *Alena Prokharchyk >> *Subject: *Re: Review Request 20099: Domain-Account-User Sync Up Among >> Multiple Regions (Core Changes) >> >> >> >> Will this change work? >> >> >> >> @Parameter(name =3D ApiConstants.ORIGINATED_REGION_ID, type =3D >> CommandType.UUID, description =3D "Region UUID where this account is >> created.", since =3D "4.5") >> >> private String originatedRegionUUID; >> >> >> >> >> >> On Tue, Jun 24, 2014 at 3:25 PM, Alex Ough >> wrote: >> >> Alena, >> >> >> >> This is what really frustrates me, but can you give the final items >> instead of keeping adding more items whenever I post a review, please? >> >> Can you gurantee that this is the only item you want me to fix? >> >> >> >> On Tue, Jun 24, 2014 at 3:04 PM, Alena Prokharchyk < >> Alena.Prokharchyk@citrix.com> wrote: >> >> Alex, as a part of the fix, also change the param name to be regionId >> (there should be a value in apiconstants already) as the parameter reall= y >> reflects CS region object, and we usually refer to those as networkID, >> vpcID (not uuid) although uuid are passed in. Check if the rest of the a= pi >> changes you've done, respect this rule. Sorry, out of the office now and >> cant check myself if there are any. >> >> -alena >> >> >> > On Jun 24, 2014, at 11:12 AM, "Alena Prokharchyk" < >> alena.prokharchyk@citrix.com> wrote: >> > >> > >> > ----------------------------------------------------------- >> >> > This is an automatically generated e-mail. To reply, visit: >> >> > https://reviews.apache.org/r/20099/#review46557 >> > ----------------------------------------------------------- >> >> > >> > >> > Alex, one small thing. >> > >> > Just noticed that in the API commands you pass regionUUID as a string. >> You should pass it as a type of UUID and specify the entityType paramete= r >> in @Parameter so the entity validation is done correctly. Example: >> > >> > @Parameter(name=3DApiConstants.ZONE_ID, type=3DCommandType.UUID, entit= yType >> =3D ZoneResponse.class, >> > required=3Dtrue, description=3D"the Zone ID for the network= ") >> > private Long zoneId; >> > >> > That is the rule when passing id/uuid of the first class CS object to >> the API call >> > >> > Then be aware of the fact that the APIDispatcher will transform UUID t= o >> the actual DB id, and that would be the Id that you pass to the services >> call. If what you need is UUID, not the actual id, to be saved in the >> callContext, you have to transform it explicitly. >> > >> > - Alena Prokharchyk >> > >> > >> >> >> On June 24, 2014, 3:54 p.m., Alex Ough wrote: >> >> >> >> ----------------------------------------------------------- >> >> >> This is an automatically generated e-mail. To reply, visit: >> >> https://reviews.apache.org/r/20099/ >> >> >> ----------------------------------------------------------- >> >> >> >> (Updated June 24, 2014, 3:54 p.m.) >> >> >> >> >> >> Review request for cloudstack. >> >> >> >> >> >> Repository: cloudstack-git >> >> >> >> >> >> Description >> >> ------- >> >> >> >> >> This is the review request for the core changes related with #17790 >> that has only the new plugin codes. >> >> >> >> >> >> >> Diffs >> >> ----- >> >> >> >> api/src/com/cloud/event/EventTypes.java 0fa3cd5 >> >> >> api/src/com/cloud/user/AccountService.java eac8a76 >> >> api/src/com/cloud/user/DomainService.java 4c1f93d >> >> api/src/org/apache/cloudstack/api/ApiConstants.java adda5f4 >> >> api/src/org/apache/cloudstack/api/BaseCmd.java ac9a208 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCm= d.java >> 50d67d9 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCm= d.java >> 5754ec5 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountC= md.java >> 3e5e1d3 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCm= d.java >> f30c985 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.= java >> 3c185e4 >> >> >> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCm= d.java >> a7ce74a >> >> >> api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainCmd.= java >> 312c9ee >> >> >> api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainCmd.= java >> a6d2b0b >> >> >> api/src/org/apache/cloudstack/api/command/admin/domain/UpdateDomainCmd.= java >> 409a84d >> >> >> api/src/org/apache/cloudstack/api/command/admin/region/AddRegionCmd.jav= a >> f6743ba >> >> >> api/src/org/apache/cloudstack/api/command/admin/region/UpdateRegionCmd.= java >> b08cbbb >> >> >> api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java >> 8f223ac >> >> >> api/src/org/apache/cloudstack/api/command/admin/user/DeleteUserCmd.java >> 08ba521 >> >> >> api/src/org/apache/cloudstack/api/command/admin/user/DisableUserCmd.jav= a >> c6e09ef >> >> >> api/src/org/apache/cloudstack/api/command/admin/user/EnableUserCmd.java >> d69eccf >> >> api/src/org/apache/cloudstack/api/command/admin/user/LockUserCmd.jav= a >> 69623d0 >> >> api/src/org/apache/cloudstack/api/command/admin/user/RegisterCmd.jav= a >> 2090d21 >> >> >> api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java >> f21e264 >> >> api/src/org/apache/cloudstack/api/response/RegionResponse.java 6c74f= a6 >> >> api/src/org/apache/cloudstack/region/Region.java df64e44 >> >> api/src/org/apache/cloudstack/region/RegionService.java afefcc7 >> >> api/test/org/apache/cloudstack/api/command/test/RegionCmdTest.java >> 10c3d85 >> >> client/pom.xml 29fef4f >> >> >> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-c= ore-daos-context.xml >> 2ef0d20 >> >> engine/schema/src/com/cloud/user/AccountVO.java 0f5a044 >> >> engine/schema/src/org/apache/cloudstack/region/RegionVO.java 608bd2b >> >> >> plugins/network-elements/juniper-contrail/test/org/apache/cloudstack/ne= twork/contrail/management/MockAccountManager.java >> 4136b5c >> >> plugins/pom.xml b5e6a61 >> >> >> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/= LdapCreateAccountCmd.java >> b753952 >> >> >> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/= LdapImportUsersCmd.java >> 6f7be90 >> >> >> server/src/com/cloud/api/ApiResponseHelper.java f1f0d2c >> >> server/src/com/cloud/api/dispatch/ParamProcessWorker.java 1592b93 >> >> server/src/com/cloud/event/ActionEventUtils.java 2b3cfea >> >> server/src/com/cloud/projects/ProjectManagerImpl.java d10c059 >> >> server/src/com/cloud/user/AccountManager.java 194c5d2 >> >> server/src/com/cloud/user/AccountManagerImpl.java 7a889f1 >> >> server/src/com/cloud/user/DomainManager.java f72b18a >> >> server/src/com/cloud/user/DomainManagerImpl.java fbbe0c2 >> >> server/src/org/apache/cloudstack/region/RegionManager.java 6f25481 >> >> server/src/org/apache/cloudstack/region/RegionManagerImpl.java 89107= 14 >> >> server/src/org/apache/cloudstack/region/RegionServiceImpl.java 98cf5= 00 >> >> server/test/com/cloud/user/AccountManagerImplTest.java 176cf1d >> >> server/test/com/cloud/user/MockAccountManagerImpl.java 746fa1b >> >> server/test/com/cloud/user/MockDomainManagerImpl.java 7dddefb >> >> server/test/org/apache/cloudstack/region/RegionManagerTest.java >> d7bc537 >> >> setup/db/db/schema-440to450.sql ee419a2 >> >> ui/scripts/regions.js 368c1bf >> >> >> >> Diff: https://reviews.apache.org/r/20099/diff/ >> >> >> >> >> >> Testing >> >> ------- >> >> >> >> >> 1. Successfully tested real time synchronization as soon as resources >> are created/deleted/modified in one region. >> >> 2. Successfully tested full scans to synchronize resources that were >> missed during real time synchronization because of any reasons like netw= ork >> connection issues. >> >> 3. The tests were done manually and also automatically by randomly >> generating changes each region. >> >> >> >> >> >> >> Thanks, >> >> >> >> Alex Ough >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > --089e0149333e6dec0b04fcb32fd0--