[
https://issues.apache.org/jira/browse/LIBCLOUD-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13725793#comment-13725793
]
John Carr commented on LIBCLOUD-367:
------------------------------------
As per IRC conversation earlier:
The end result of this issue is that we can trust the 'create_node' metadata,
and that deploy_node continues to function as it does currently.
I plan to:
* Update deploy_node to accept NodeAuth* objects whether or not the
create_node API does and attempt to use them for authentication. A positive
side effect of this change is that this allows deploy_node to work where a key
or password is baked into an image as well.
* If features['create_node'] supports a NodeAuthSSHKey ('ssh_key') or
NodeAuthPassword ('password') and one is supplied to deploy_node, it will be
passed to create_node. Otherwise the auth arg will not be forwarded to the
create_node implementation
* If features['create_node'] supports generate_password and no auth param is
supplied deploy_node will use the generated password. But it will prefer
provided authentication details if they are given.
* I will audit the compute nodes to ensure that their feature flags are set
correctly:
** abiquo - claims to support password but does not. Will remove metadata.
** bluebox - has no features, but supports NodeAuthSSHKey and
NodeAuthPassword. Will fix metadata.
** brightbox - claims to support ssh_key but does not. Will remove metadata.
** digitalocean - claims to support ssh_key, but not via auth parameter.
Initially I will just remove the feature metadata.
** ec2 - claims to support ssh_key, but not via auth parameter. For now I
will just remove the feature metadata.
** hostvirtual - supports NodeAuthSSHKey and NodeAuthPassword, but doesnt
have feature metadata. Will fix metadata.
** rimuhosting - already takes NodeAuthPassword but only claims to support
generates_password. Support both.
I would also like to update the sphinx docs if they have landed in trunk when I
have completed these changes. If they haven't i'll do a seperate PR.
I have identified some areas that could be improved and which I hope to work on:
* cloudstack - this should be able to support NodeAuthSSHKey
* digitialocean - this should be able to support NodeAuthSSHKey
* ec2 - this could automatically create a keypair record and use it when a key
is passed to the auth argument
* gandi - could support NodeAuthPassword quite easily, but need to think about
usernames.
* ibm_sce - does not support NodeAuthSSHKey properly (expects pubkey to be a
key *name*, not a key!!). Fix it.
* voxel - Update to support NodeAuthPassword (equivalent to setting
ex_rootpass?)
> Proper use of create_node and NodeAuthSSHKey
> --------------------------------------------
>
> Key: LIBCLOUD-367
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-367
> Project: Libcloud
> Issue Type: Bug
> Components: Compute
> Reporter: John Carr
>
> I've read through the documentation and code and it's not clear to me the
> proper way to do this.
> My wishful thinking is that I can pass NodeAuthSSHKey to a Driver's
> create_node function as the 'auth' argument... *if*
> driver.features['create_node'] contains 'ssh_key'. Likewise NodeAuthPassword
> is used to set the initial password when the 'create_node' feature contains
> 'password'.
> However the code doesn't really back that up, and EC2 in particular doesn't
> support that.
> Is there an interface to determine if I can pass NodeAuth* to create_node? If
> there is, what is it? I will then submit patches to advertise support for
> NodeAuth* on drivers that do and try and improve the docs.
> If there isn't, I would like to add one. The one I described would be the
> ideal one, i think, but it would have side effects on EC2/deploy_node?
--
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
