[
https://issues.apache.org/jira/browse/LIBCLOUD-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753933#comment-13753933
]
John Carr commented on LIBCLOUD-388:
------------------------------------
[~sebgoa],
In trunk deploy_node is totally decoupled from self.features['create_node'].
That metadata is only used right now to indicate what kinds of values you can
pass to the auth argument. Note that this doesn't mean you *have* to pass them
to the auth argument, auth can be None. So you are correct - it is possible to
provide *NO* authentication related information to create_node, but deploy_node
would still work. This is by design. Some services don't actually let you
specify a password, ssh key or keyring name at all, and deploy_node will still
work for them. So it is possible for deploy_node to work even if the features
dict is entirely empty!
I do agree that for services that have a keyring and people know what their key
is called already then it makes sense to continue to support the ex_keyname
API. So definitely don't remove the ex_keyname API. But there are hosting
services that take the pubkey and don't have a keyring. The find_or_import
approach means we can have a single API that works for services with or without
a keyring, as well as the ex_keyname API for the services with a keyring.
> deploy_node not supported in cloudstack driver
> ----------------------------------------------
>
> Key: LIBCLOUD-388
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-388
> Project: Libcloud
> Issue Type: Bug
> Components: Compute
> Affects Versions: 0.12.3
> Reporter: sebastien goasguen
> Attachments: libcloud388.patch
>
>
> deploy_node not available due to lack of auth
--
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
