[
https://issues.apache.org/jira/browse/JCLOUDS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691643#comment-13691643
]
ASF subversion and git services commented on JCLOUDS-105:
---------------------------------------------------------
Commit 091881ab209c9098e93b5730016bb23800ffa188 in branch refs/heads/1.6.x from
[~abayer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git;h=091881a ]
JCLOUDS-105 - fixing CloudStack logic for case where password is not enabled
*and* no keypair is specified
> 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
> Fix For: 1.7.0, 1.6.1, 1.5.11
>
>
> 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
