Details
Improvement
Major
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
- All
- Comments
- Work Log
- History
- Activity
- Transitions
/cc Brian Curtin, Alex Gaynor
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
Github user asfgit closed the pull request at:
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.