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 9 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 9 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 almost 9 years ago
- Has duplicate Bug #14210: Provisioning via API doesn't start the host by default added
Updated by Dominic Cleal almost 9 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 almost 9 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 8 years ago
- Has duplicate Bug #14325: VM does not start after creation when using a compute profile added