[
https://issues.apache.org/jira/browse/CLOUDSTACK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258464#comment-14258464
]
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: https://issues.apache.org/jira/browse/CLOUDSTACK-7073
> 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
(v6.3.4#6332)
