[
https://issues.apache.org/jira/browse/LIBCLOUD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911805#comment-13911805
]
Michael Rommel commented on LIBCLOUD-356:
-----------------------------------------
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.
> Provide user-data for Openstack driver
> --------------------------------------
>
> Key: LIBCLOUD-356
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-356
> Project: Libcloud
> Issue Type: Improvement
> Components: Compute
> Affects Versions: 0.12.3
> Environment: Libcloud 0.13.0 against Openstack
> Reporter: Mattieu Puel
> Labels: cloud-init, openstack, userdata
> Fix For: 0.12.3
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
