[
https://issues.apache.org/jira/browse/CLOUDSTACK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258453#comment-14258453
]
Alena Prokharchyk commented on CLOUDSTACK-7073:
-----------------------------------------------
1) "Yes we have allowed DB to have duplicated usernames, since there is never a
unique constraint added on that field. From functionality perspective, we can
delete a user and create another with same username - so in the DB, two entries
with same username exist."
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.
"2) We cannot just put back the original fix without having fixes in other
areas:
a) Upgrade step is needed to take care of existing customer schemas. Without
that step this fix is not complete."
- 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.
"b) In the upgrade and in the API code we need to decide on what to set the
username field to for the removed users, when we have to introduce these
constraints. Simply setting it to NULL is erasing the user history. Also this
needs to be evaluated how it affects the usage functionality. Will setting it
simply to null affect any usage record collection?"
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.
"c) There is another way to fix this using the DB constraints - by having
another column say 'inactive' (boolean) tied up with the username and domainid.
What this solves is the limitation of the 'removed' column not being useful
since it can have a null value and MySQL unique constraint wont work with null.
Ofcourse, upgrade step is needed here for existing schemas."
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
"d) Also this can be fixed through the code by having a global lock when we
check if the username is already existing during user creation. This will solve
the issue with cluster management setup, No?"
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.
> 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: Alena Prokharchyk
> Fix For: 4.6.0
>
>
> 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)
