cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8727) API call listVirtualMachines returns same keypair
Date Wed, 12 Aug 2015 13:24:46 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14693471#comment-14693471
] 

ASF GitHub Bot commented on CLOUDSTACK-8727:
--------------------------------------------

Github user kansal commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/685#discussion_r36858306
  
    --- Diff: setup/db/db/schema-452to460.sql ---
    @@ -353,6 +353,8 @@ CREATE VIEW `cloud`.`user_vm_view` AS
             `cloud`.`user_vm_details` `custom_speed`  ON (((`custom_speed`.`vm_id` = `cloud`.`vm_instance`.`id`)
and (`custom_speed`.`name` = 'CpuSpeed')))
                left join
             `cloud`.`user_vm_details` `custom_ram_size`  ON (((`custom_ram_size`.`vm_id`
= `cloud`.`vm_instance`.`id`) and (`custom_ram_size`.`name` = 'memory')));
    +        delete s1 from ssh_keypairs s1, ssh_keypairs s2 where s1.id > s2.id and s1.public_key
= s2.public_key;
    +        ALTER TABLE ssh_keypairs ADD UNIQUE (fingerprint);
    --- End diff --
    
    @sedukullI have deleted the lines with the same public_key because we want that previous
different name-same key registrations are handled. (I mean the ones people will already have
in their DB). For putting the unique constraint, I added it on the fingerprint because the
public_key is a VARCHAR(5120) and our DB doesn't allow unique key on such large values. It
won't be a problem because finger print is generated from the public_key only. 
    Coming to deleting the rows, I am deleting the ones with newer(large) id's. If required,
older ones can be deleted and newest can be kept.(no big deal).
    
    @DaanHoogland Being new to the community, I was not aware of the fact that we have take
these to Mailing lists. If you want I can do that also. 
    
    @sedukull as far as the api changes are concerned, I don't think that is necessary. Its
not generating the duplicates in the main table. What happens is that in the logic, there
is join between ssh_keypairs and user_vm_details to create user_vm_view on the basis of public_key.
Since public_key is not a foreign key, such kind of issues are arising. 
    For "cascading delete logic" I will get back to you in detail. But it worked fine for
me.


> API call listVirtualMachines returns same keypair
> -------------------------------------------------
>
>                 Key: CLOUDSTACK-8727
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8727
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: Kshitij Kansal
>
> If you register 2 SSH keypairs with the same public key then listVirtualMachines API
call will only return the first keypair. Although its a very rare case and generally don't
make much sense by registering the same key with different name, still it can be fixed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message