cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alena Prokharchyk (JIRA)" <j...@apache.org>
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:04:13 GMT

    [ 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)

Mime
View raw message