Bug #10223
open
Image provisoning over API doesn't start host automatically
Description
Foreman 1.8rc3
Debian Wheezy
curl -s -X $METHOD -H "Accept:application/json" -H "Content-Type:application/json" \
-k -u $USER:$PASS \
-d '{"host":"name":"test1","hostgroup_id":"1","operatingsystem_id":"1","image_id":"1","compute_resource_id":"1","compute_profile_id":"1","provision_method":"image","subnet_id":"1","compute_attributes":{ "start":"1","vm_attrs":{ "cpus":"4"}}}}' \
$FOREMAN_URL/api/v2/hosts | json_pp
The machine is created through libvirt provider but the virtual machine doesnt have a filesystem with content in it so it just says "No boot device" in the console. If i drop the compute_attributes and just power up the machine manually it all works..except i have to manually power up the machine after the api call (which waits for the machine to come up)
debug put up at:
rsync /tmp/foreman-debug-ngR17.tar.xz rsync://theforeman.org/debug-incoming
Updated by El Joppa over 11 years ago
After alot of debugging and retrying i got to build a host correctly with image through the api with autostart of the virtual machine in libvirt.
If you touch compute_attributes you have to complete the whole block with more data to get it done correctly.
Attaching example for other users having issues with this:
curl -s -X POST -H "Accept:application/json" -H "Content-Type:application/json" \
-k -u $USER:$PASS \
-d \
'{"host":{
"name":"'$NAME'",
"hostgroup_id":"1",
"compute_resource_id":"1",
"compute_profile_id":"1",
"environment_id":"1",
"puppet_ca_proxy_id":"",
"puppet_proxy_id":"",
"salt_environment_id":"3",
"salt_proxy_id":"3",
"salt_module_ids":[
""
],
"puppetclass_ids":[
""
],
"managed":"true",
"progress_report_id":"[FILTERED]",
"type":"Host::Managed",
"compute_attributes":{
"cpus":"1",
"memory":"805306368",
"start":"1",
"volumes_attributes": {
"0": {
"_delete": "",
"pool_name": "default",
"capacity": "10G",
"allocation": "0G",
"format_type": "qcow2"
},
"new_volumes": {
"_delete": "",
"pool_name": "default",
"capacity": "10G",
"allocation": "0G",
"format_type": "raw"
}
},
"image_id":"/var/lib/libvirt/images/foo.img"
},
"architecture_id":"1",
"subnet_id":"1",
"operatingsystem_id":"1",
"provision_method":"image",
"build":"1",
"medium_id":"2",
"ptable_id":"9",
"disk":"",
"enabled":"1",
"model_id":"",
"comment":"",
"overwrite":"false"
}}' \
$FOREMAN_URL/api/v2/hosts | json_pp
Updated by Dorian D over 11 years ago
I have this exact same problem. It would be great if we could use "start":"1" without explicitly setting the rest of the compute_attributes. These should already be set through the compute profile and shouldn't have to be set again when posting to the api.
Updated by Dominic Cleal over 10 years ago
- Has duplicate Bug #14210: Provisioning via API doesn't start the host by default added
Updated by Dominic Cleal over 10 years ago
- Subject changed from Do not get image provision to work over api to Image provisoning over API doesn't start host automatically
Regarding compute attributes, the fix in #6342 to merge attributes supplied in the API with those from the compute profile is now available in Foreman 1.11. This means you can now pass just {"compute_attributes":{"start":"1"}} without needing to duplicate the rest.
Leaving this open because host creation over the API should still start the VM automatically like the UI default.
Updated by Dominic Cleal over 10 years ago
- Related to Bug #6342: Compute profile should be used when empty volumes and interfaces passed in compute_attributes added
Updated by Dominic Cleal over 10 years ago
- Has duplicate Bug #14325: VM does not start after creation when using a compute profile added