cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prachi Damle (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-7073) Account/User creation: able to create user with the same name in the same domain in Clustered MS setup
Date Wed, 24 Dec 2014 19:20:13 GMT


Prachi Damle commented on CLOUDSTACK-7073:

>>>We never allowed that on the functional (java) level. Check the code, there was
always a restriction. The case was breaking in a cluster management setup because the record
in the DB wasn't locked. But in a single management server setup the lock in the code always
prevented duplicated names from happening.

Yes, I know that. What I mean is without the db constraint duplicate username is allowed to
exist so far by the system.
Having the code fix anyway breaks in the clustered setup. 

>>>Customer should take care of it himself. The upgrade should be fixed only by Alerting
that his table contains the duplicates, and the upgrade can't 
proceed further. We should never automatically remove the records on his behalf.

I dont agree to this. We have put the customer in this situation due to this design around
the user table to start with. So our cleanup should have taken care of ideally. So if now
we rae adding constraints we need to take care of the existing schemas.
So this fix is not complete without adding upgrade steps to take care of these setups.

>>>We never end the history. History is saved in the events - create/deleteuser events.
As per usage, its done based on the account name, not the username.
Setting username to null is erasing history - having it in events table is of what good if
we cannot track it back to exactly which user record in the db? We wont be able to map the
events record back to the user record and other user properties since the user became null.
Instead its should be set to something like 'username_removed_time' or some other format from
which username can be linked back

>>>That wouldn't work, as you can't still have more than one record with the same
username, domain_id and state="inactive". In other words, the second user with the same userName
can be added after the first user is removed, and its state will be "active". But this user
can never be removed as there is already removed records with the same field values for the
user #1

Add removed field to the constraint as well to make it work. 

>>>Global lock won't be a good solution, as in this scenario it should be put on
the entire cloud.user table. Locking this table is not a good idea as its being references
by 10000 places in the code, and locking it will be costly.

I dont think it will be a costly operation since it will be a very small check done under
that lock, we should minimize the locked code only to the minimal check and update part.
The only part I am not sure about is how many places this code of adding a user is scattered
on in cloudstack. 

> Account/User creation: able to create user with the same name in the same domain in Clustered
MS setup
> ------------------------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-7073
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.5.0
>            Reporter: Alena Prokharchyk
>            Assignee: Prachi Damle
>             Fix For: Future
> In the Java code we prohibit user to have duplicated names inside the same domain. But
in the DB the constraint is missing in cloud.account/cloud.user table, so it is still possible
to violate the rule by initiating the create call from parallel threads issued either by the
same MS, or by multiple MS in the clustered MS setup.
> To fix, have to introduce some kind of the global lock, or db constraint preventing multiple
threads to insert the record with the same username.

This message was sent by Atlassian JIRA

View raw message