You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Andrew Bayer (JIRA)" <ji...@apache.org> on 2013/05/31 01:25:20 UTC

[jira] [Commented] (JCLOUDS-105) CloudStack instance provisioning uses password if passwordEnabled, even if a keypair is given

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

Andrew Bayer commented on JCLOUDS-105:
--------------------------------------

Hmm - the other option here would be to toss the current keypair logic and instead implement the same sort of behavior that we have in ec2 and nova, where we create keypairs on the fly by default. We probably wouldn't want to do this by default for CloudStack, since there isn't a guarantee that a CloudStack setup has support for SSH keys on its instances, but if we make that a configurable template option along with the ability to specify a keypair (like shouldGenerateKeyPair and keyPairName in nova), defaulting to false/null respectively, we've got a cleaner setup that fits with similar APIs. Yeah, I think I like that better. =)
                
> CloudStack instance provisioning uses password if passwordEnabled, even if a keypair is given
> ---------------------------------------------------------------------------------------------
>
>                 Key: JCLOUDS-105
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-105
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-compute
>    Affects Versions: 1.5.10, 1.6.0
>            Reporter: Andrew Bayer
>            Assignee: Andrew Bayer
>
> In the process of trying to figure out WHIRR-725, I eventually discovered that CloudStackComputeServiceAdapter.createNodeWithGroupEncodedIntoName will set the initial credentials for the VM to be the autogenerated password no matter what, if passwordEnabled=true on the VM, even if you've explicitly specified an SSH keypair. This caused problems with init scripts (i.e., they couldn't run since it couldn't authenticate) with exoscale, who have passwordEnabled=true on their images, but block password authentication over SSH. 
> There's a pretty easy fix for this - in the method in question, just flip it so that the password option is only used if passwordEnabled is true *and* there is no keypair specified in the template options. Patch incoming.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira