Uploaded image for project: 'Libcloud'
  1. Libcloud
  2. LIBCLOUD-367

Proper use of create_node and NodeAuthSSHKey

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.14.0-beta3
    • Component/s: Compute
    • Labels:
      None

      Description

      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?

        Activity

        Hide
        kami Tomaz Muraus added a comment -

        (quick recap from an IRC discussion)

        Yes, your first paragraph is correct - that was the original goal. The problem is that currently, not a lot of create_node methods take "auth" kwarg. There is also no nice way to determine if a create_node supports that argument.

        There is features['create_node'], but not all of the drivers which advertise 'ssh_key' or 'password' in features['create_node'] actually take "auth" kwarg in the create_node method.

        Show
        kami Tomaz Muraus added a comment - (quick recap from an IRC discussion) Yes, your first paragraph is correct - that was the original goal. The problem is that currently, not a lot of create_node methods take "auth" kwarg. There is also no nice way to determine if a create_node supports that argument. There is features ['create_node'] , but not all of the drivers which advertise 'ssh_key' or 'password' in features ['create_node'] actually take "auth" kwarg in the create_node method.
        Hide
        jc2k John Carr added a comment -

        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?)
        Show
        jc2k John Carr added a comment - 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?)
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 7771ae72d8daac273fc759cd654c58631ec0af05 in branch refs/heads/trunk from John Carr
        [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=7771ae7 ]

        Fix create_node feature metadata (LIBCLOUD-367)

        Signed-off-by: Tomaz Muraus <tomaz@apache.org>

        Show
        jira-bot ASF subversion and git services added a comment - Commit 7771ae72d8daac273fc759cd654c58631ec0af05 in branch refs/heads/trunk from John Carr [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=7771ae7 ] Fix create_node feature metadata ( LIBCLOUD-367 ) Signed-off-by: Tomaz Muraus <tomaz@apache.org>
        Hide
        kami Tomaz Muraus added a comment -

        Thanks, I've merged this PR into trunk.

        This branch also exposed some encoding related Python 3.x bugs which I fixed in commit 05e8559d4321c27f32cdbe0c913b334f0c1b60ae.

        Show
        kami Tomaz Muraus added a comment - Thanks, I've merged this PR into trunk. This branch also exposed some encoding related Python 3.x bugs which I fixed in commit 05e8559d4321c27f32cdbe0c913b334f0c1b60ae.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 506c0fc07aaeb5c7477c3ab920d5e1a48777bb12 in branch refs/heads/0.13.x from John Carr
        [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=506c0fc ]

        Fix create_node feature metadata (LIBCLOUD-367)

        Signed-off-by: Tomaz Muraus <tomaz@apache.org>

        Conflicts:
        libcloud/compute/drivers/ec2.py

        Show
        jira-bot ASF subversion and git services added a comment - Commit 506c0fc07aaeb5c7477c3ab920d5e1a48777bb12 in branch refs/heads/0.13.x from John Carr [ https://git-wip-us.apache.org/repos/asf?p=libcloud.git;h=506c0fc ] Fix create_node feature metadata ( LIBCLOUD-367 ) Signed-off-by: Tomaz Muraus <tomaz@apache.org> Conflicts: libcloud/compute/drivers/ec2.py

          People

          • Assignee:
            kami Tomaz Muraus
            Reporter:
            jc2k John Carr
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development