libcloud-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Carr (JIRA)" <>
Subject [jira] [Commented] (LIBCLOUD-388) deploy_node not supported in cloudstack driver
Date Thu, 29 Aug 2013 18:48:52 GMT


John Carr commented on LIBCLOUD-388:


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

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:
>             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:

View raw message