cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)
Date Tue, 24 Jun 2014 23:13:13 GMT
Moving the discussion to the mailing list as it doesn’t have to be private. Kishan/Murali,
can you please follow up on the remaining review for (see
my last comment and the discussion below)

Basically what Alex wants to do is – pass the originated region to create/update/deleteAccount
commands. And the question is – what type this parameter should have (see details below)


From: Alena Prokharchyk <<>>
Date: Tuesday, June 24, 2014 at 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

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 “region” table
to be populated with the same id/name in both Dbs for both regions, right? So my question
is – what uniquely identifies the region in CS system in cross region setup – id/name?

That unique identifier should be the value that is passed to the calls you modify, Alex. WE
can’t just pass some random name to the call without making any further verification.

Kishan/Murali, please help to verify this part of Alex’s fix as it should really be someone
with an expertise in Regions. I’ve reviewed the rest of the feature, just this one item
is open. See my latest comment to the as
well as refer to this email thread for the context.


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

That what would everybody assume 100% just by looking at the parameter description and parameter
– that you refer to region UUID : "Region where this account is created.”/ORIGINATEDREGIONUUID
In CS the UUID has a special meaning. It has to have the UUID format, and its randomly generated
value that is stored in the DB along with the actual 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’t use the region
id instead? That’s what we do when refer to CS objects – we always refer to them by id
which is unique. Which is true even for the region:

mysql> show create table region;

 UNIQUE KEY `id` (`id`),
  UNIQUE KEY `name` (`name`)

That’s 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:


Please correct if I miss something.

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

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.

Alex Ough

On Tue, Jun 24, 2014 at 5:17 PM, Alena Prokharchyk <<>>

take a look at ParamProcessWorker class, and how API parameters are being 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, final 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())
                    final Long internalId = translateUuidToInternalId(paramObj.toString(),
                    field.set(cmdObj, internalId);

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 to 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);"

Hope it answers your questions, and let me know if anything else needs to be clarified.


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

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 <<>>
You need to put:

*  the entityType parameter to the annotation.

  *   Change the type to Long as I’ve already mentioned. Check how other commands handle
the parameters (networkId, vpcId, etc)


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

Will this change work?

    @Parameter(name = ApiConstants.ORIGINATED_REGION_ID, type = CommandType.UUID, description
= "Region UUID where this account is created.", since = "4.5")
    private String originatedRegionUUID;

On Tue, Jun 24, 2014 at 3:04 PM, Alena Prokharchyk <<>>
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 really 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 api changes you've done, respect this rule. Sorry, out of the office now and cant check
myself if there are any.


> On Jun 24, 2014, at 11:12 AM, "Alena Prokharchyk" <<>>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> -----------------------------------------------------------
> 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 parameter in @Parameter so the entity validation
is done correctly. Example:
> @Parameter(name=ApiConstants.ZONE_ID, type=CommandType.UUID, entityType = ZoneResponse.class,
>            required=true, description="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 to 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:
>> -----------------------------------------------------------
>> (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/ 0fa3cd5
>>  api/src/com/cloud/user/ eac8a76
>>  api/src/com/cloud/user/ 4c1f93d
>>  api/src/org/apache/cloudstack/api/ adda5f4
>>  api/src/org/apache/cloudstack/api/ ac9a208
>>  api/src/org/apache/cloudstack/api/command/admin/account/ 50d67d9
>>  api/src/org/apache/cloudstack/api/command/admin/account/ 5754ec5
>>  api/src/org/apache/cloudstack/api/command/admin/account/ 3e5e1d3
>>  api/src/org/apache/cloudstack/api/command/admin/account/ f30c985
>>  api/src/org/apache/cloudstack/api/command/admin/account/ 3c185e4
>>  api/src/org/apache/cloudstack/api/command/admin/account/ a7ce74a
>>  api/src/org/apache/cloudstack/api/command/admin/domain/ 312c9ee
>>  api/src/org/apache/cloudstack/api/command/admin/domain/ a6d2b0b
>>  api/src/org/apache/cloudstack/api/command/admin/domain/ 409a84d
>>  api/src/org/apache/cloudstack/api/command/admin/region/ f6743ba
>>  api/src/org/apache/cloudstack/api/command/admin/region/ b08cbbb
>>  api/src/org/apache/cloudstack/api/command/admin/user/ 8f223ac
>>  api/src/org/apache/cloudstack/api/command/admin/user/ 08ba521
>>  api/src/org/apache/cloudstack/api/command/admin/user/ c6e09ef
>>  api/src/org/apache/cloudstack/api/command/admin/user/ d69eccf
>>  api/src/org/apache/cloudstack/api/command/admin/user/ 69623d0
>>  api/src/org/apache/cloudstack/api/command/admin/user/ 2090d21
>>  api/src/org/apache/cloudstack/api/command/admin/user/ f21e264
>>  api/src/org/apache/cloudstack/api/response/ 6c74fa6
>>  api/src/org/apache/cloudstack/region/ df64e44
>>  api/src/org/apache/cloudstack/region/ afefcc7
>>  api/test/org/apache/cloudstack/api/command/test/ 10c3d85
>>  client/pom.xml 29fef4f
>>  engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>>  engine/schema/src/com/cloud/user/ 0f5a044
>>  engine/schema/src/org/apache/cloudstack/region/ 608bd2b
>>  plugins/network-elements/juniper-contrail/test/org/apache/cloudstack/network/contrail/management/
>>  plugins/pom.xml b5e6a61
>>  plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/
>>  plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/
>>  server/src/com/cloud/api/ f1f0d2c
>>  server/src/com/cloud/api/dispatch/ 1592b93
>>  server/src/com/cloud/event/ 2b3cfea
>>  server/src/com/cloud/projects/ d10c059
>>  server/src/com/cloud/user/ 194c5d2
>>  server/src/com/cloud/user/ 7a889f1
>>  server/src/com/cloud/user/ f72b18a
>>  server/src/com/cloud/user/ fbbe0c2
>>  server/src/org/apache/cloudstack/region/ 6f25481
>>  server/src/org/apache/cloudstack/region/ 8910714
>>  server/src/org/apache/cloudstack/region/ 98cf500
>>  server/test/com/cloud/user/ 176cf1d
>>  server/test/com/cloud/user/ 746fa1b
>>  server/test/com/cloud/user/ 7dddefb
>>  server/test/org/apache/cloudstack/region/ d7bc537
>>  setup/db/db/schema-440to450.sql ee419a2
>>  ui/scripts/regions.js 368c1bf
>> 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 network connection issues.
>> 3. The tests were done manually and also automatically by randomly generating changes
each region.
>> Thanks,
>> Alex Ough

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message