Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.12.3
    • Fix Version/s: 0.12.3
    • Component/s: Compute
    • Environment:

      Libcloud 0.13.0 against Openstack

      Description

      libcloud openstack's driver supports parameter "user-data" (namely ex_userdata) for providing user data to the instance. This is the equivalent to "nova boot --user-data" parameter.

      With Openstack nova command, this results in providing the content of the pointed file. You may for instance provide a shell script, a configuration file for cloud-init...

      Once the VM startups, cloud-init retrieves the file from the metadata server and uses it (executes it for shell scripts for instance).

      The libcloud behaviour is different: it simply passes the parameter content as is.

        Activity

        Hide
        githubbot ASF GitHub Bot added a comment -

        Github user asfgit closed the pull request at:

        https://github.com/apache/libcloud/pull/330

        Show
        githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/libcloud/pull/330
        Hide
        githubbot ASF GitHub Bot added a comment -

        GitHub user stickystyle opened a pull request:

        https://github.com/apache/libcloud/pull/330

        LIBCLOUD-356 Add config_drive to support user_data

        You can merge this pull request into a Git repository by running:

        $ git pull https://github.com/stickystyle/libcloud patch-1

        Alternatively you can review and apply these changes as the patch at:

        https://github.com/apache/libcloud/pull/330.patch

        To close this pull request, make a commit to your master/trunk branch
        with (at least) the following in the commit message:

        This closes #330


        commit 23b4f14a41a4822cea7b598d529379529300d018
        Author: Ryan Parrish <ryanpublic@stickystyle.net>
        Date: 2014-06-28T11:51:14Z

        LIBCLOUD-356 Add config_drive to support user_data


        Show
        githubbot ASF GitHub Bot added a comment - GitHub user stickystyle opened a pull request: https://github.com/apache/libcloud/pull/330 LIBCLOUD-356 Add config_drive to support user_data You can merge this pull request into a Git repository by running: $ git pull https://github.com/stickystyle/libcloud patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/libcloud/pull/330.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #330 commit 23b4f14a41a4822cea7b598d529379529300d018 Author: Ryan Parrish <ryanpublic@stickystyle.net> Date: 2014-06-28T11:51:14Z LIBCLOUD-356 Add config_drive to support user_data
        Hide
        kami Tomaz Muraus added a comment -
        Show
        kami Tomaz Muraus added a comment - /cc Brian Curtin , Alex Gaynor
        Hide
        michaelrommel Michael Rommel added a comment -

        Actually, I think this issue is mostly resolved in the current version of libcloud. Using salt-cloud (which in turn uses libcloud) I can successfully pass a --user-data file which gets appropriately send to openstack. What is missing though, is that the "config_drive": true parameter also gets passed on to Openstack, therefore the creation of the config_drive fails.

        Here is an example of a compute-node with two running instances - one from nova and one via libcloud.

        root@flycatcher:/var/lib/nova/instances# find .
        .
        ./48711a02-3520-497d-963c-5a08c7745761
        ./48711a02-3520-497d-963c-5a08c7745761/console.log
        ./48711a02-3520-497d-963c-5a08c7745761/disk.config <-- this is the instance from the nova boot command line
        ./48711a02-3520-497d-963c-5a08c7745761/disk
        ./48711a02-3520-497d-963c-5a08c7745761/libvirt.xml
        ./69037e7a-e1a3-401d-b2a6-e7193b61a748
        ./69037e7a-e1a3-401d-b2a6-e7193b61a748/console.log
        ./69037e7a-e1a3-401d-b2a6-e7193b61a748/disk <-- the salt-cloud/libcloud instance is missing the config_drive
        ./69037e7a-e1a3-401d-b2a6-e7193b61a748/libvirt.xml
        ./compute_nodes
        ./locks
        ./locks/nova-var_lib_nova_instances_base_2296e810ae1fb998bcf10f6b8855eab41839ee06
        ./locks/nova-var_lib_nova_instances_base_9c5d06c1743b0c02e1cc688efc3d7d55b71bf5ce
        ./locks/nova-2296e810ae1fb998bcf10f6b8855eab41839ee06
        ./locks/nova-storage-registry-lock
        ./locks/nova-9c5d06c1743b0c02e1cc688efc3d7d55b71bf5ce
        ./_base
        ./_base/2296e810ae1fb998bcf10f6b8855eab41839ee06

        If I start an instance from the nova boot line, this gets submitted:

        {"server": {"name": "trusty", "imageRef": "7820539e-495d-4c32-8639-2ddfbbea6ea9", "flavorRef": "2", "user_data": "RnJvbSBub2JvZHkgU3VuIEZlYiAyMyAyMjoyODowNyAyMDE0CkNvbnRl. . . . . . . LT09PT09PT09PT09PT09PTE3OTAxMjExNDM2OTgyMzEzODA9PS0tCg==", "max_count": 1, "min_count": 1, "networks": [

        {"uuid": "ee43ec1d-0cb3-48ff-9dd1-10e9c995f4f0"}

        ], "config_drive": true}}

        This is in comparison the salt-cloud debug post to create the image:

        {"server": {"name": "salty", "imageRef": "7820539e-495d-4c32-8639-2ddfbbea6ea9", "key_name": "salt-ssh-key", "flavorRef": "2", "user_data": "RnJvbSBub2JvZHkgU3VuIEZlYiAyMyAyMjoyODowNyAyMDE0CkNvbnRl. . . . . . . LT09PT09PT09PT09PT09PTE3OTAxMjExNDM2OTgyMzEzODA9PS0tCg==", "metadata": {}, "networks": [

        {"uuid": "ee43ec1d-0cb3-48ff-9dd1-10e9c995f4f0"}

        ], "personality": []}}

        So I believe that the missing config_drive parameter is the culprit. I have checked the complete libcloud source tree and could not find any place where the parameter gets set or submitted in the REST request.

        Show
        michaelrommel Michael Rommel added a comment - Actually, I think this issue is mostly resolved in the current version of libcloud. Using salt-cloud (which in turn uses libcloud) I can successfully pass a --user-data file which gets appropriately send to openstack. What is missing though, is that the "config_drive": true parameter also gets passed on to Openstack, therefore the creation of the config_drive fails. Here is an example of a compute-node with two running instances - one from nova and one via libcloud. root@flycatcher:/var/lib/nova/instances# find . . ./48711a02-3520-497d-963c-5a08c7745761 ./48711a02-3520-497d-963c-5a08c7745761/console.log ./48711a02-3520-497d-963c-5a08c7745761/disk.config <-- this is the instance from the nova boot command line ./48711a02-3520-497d-963c-5a08c7745761/disk ./48711a02-3520-497d-963c-5a08c7745761/libvirt.xml ./69037e7a-e1a3-401d-b2a6-e7193b61a748 ./69037e7a-e1a3-401d-b2a6-e7193b61a748/console.log ./69037e7a-e1a3-401d-b2a6-e7193b61a748/disk <-- the salt-cloud/libcloud instance is missing the config_drive ./69037e7a-e1a3-401d-b2a6-e7193b61a748/libvirt.xml ./compute_nodes ./locks ./locks/nova- var_lib_nova_instances _base_2296e810ae1fb998bcf10f6b8855eab41839ee06 ./locks/nova- var_lib_nova_instances _base_9c5d06c1743b0c02e1cc688efc3d7d55b71bf5ce ./locks/nova-2296e810ae1fb998bcf10f6b8855eab41839ee06 ./locks/nova-storage-registry-lock ./locks/nova-9c5d06c1743b0c02e1cc688efc3d7d55b71bf5ce ./_base ./_base/2296e810ae1fb998bcf10f6b8855eab41839ee06 If I start an instance from the nova boot line, this gets submitted: {"server": {"name": "trusty", "imageRef": "7820539e-495d-4c32-8639-2ddfbbea6ea9", "flavorRef": "2", "user_data": "RnJvbSBub2JvZHkgU3VuIEZlYiAyMyAyMjoyODowNyAyMDE0CkNvbnRl. . . . . . . LT09PT09PT09PT09PT09PTE3OTAxMjExNDM2OTgyMzEzODA9PS0tCg==", "max_count": 1, "min_count": 1, "networks": [ {"uuid": "ee43ec1d-0cb3-48ff-9dd1-10e9c995f4f0"} ], "config_drive": true}} This is in comparison the salt-cloud debug post to create the image: {"server": {"name": "salty", "imageRef": "7820539e-495d-4c32-8639-2ddfbbea6ea9", "key_name": "salt-ssh-key", "flavorRef": "2", "user_data": "RnJvbSBub2JvZHkgU3VuIEZlYiAyMyAyMjoyODowNyAyMDE0CkNvbnRl. . . . . . . LT09PT09PT09PT09PT09PTE3OTAxMjExNDM2OTgyMzEzODA9PS0tCg==", "metadata": {}, "networks": [ {"uuid": "ee43ec1d-0cb3-48ff-9dd1-10e9c995f4f0"} ], "personality": []}} So I believe that the missing config_drive parameter is the culprit. I have checked the complete libcloud source tree and could not find any place where the parameter gets set or submitted in the REST request.

          People

          • Assignee:
            Unassigned
            Reporter:
            vodmat Mattieu Puel
          • Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 0.5h
              0.5h
              Remaining:
              Remaining Estimate - 0.5h
              0.5h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development