This example was done with VMware provisioning. The issue seems to be global and probably also affects other provisioning providers, however.

When having a compute resource defined with an image set (image_id), creating a host can either be done via image provisioning or build provisioning. Whatever is chosen within the UI means that the image_id in the compute attributes is either set and sent or not (the UI does this).

Upon using the API or calling Host.new within a plugin, image_id will always be set, since compute attributes are usually simply retrieved from the DB (which includes image_id). Setting provision_method to 'build' or 'image' doesn't make any difference and image provisioning will always be chosen.

For VMware provisioning the problem is within https://github.com/theforeman/foreman/blob/develop/app%2Fmodels%2Fcompute_resources%2Fforeman%2Fmodel%2Fvmware.rb#L322

Temporary workaround I used in a plugin:

compute_attributes = compute_resource.compute_profile_attributes_for(hostgroup.nested('compute_profile_id') || hostgroup.compute_profile_id)
# Workaround for Foreman not regarding provision_method = 'build' if image_id is set
compute_attributes[:image_id] = nil

From IRC:

Dominic | IceBear: hm, you're right. The UI applies compute profiles in the browser, and when doing an image build the image dropdown menu is disabled and hidden, so the image_id doesn't get sent back to Foreman, so it's not present. When using the API or console, everything is simply copied from the profile into the attrs...
Dominic | we could probably filter it out in the `set_compute_attributes` method in Host::Managed
Dominic | or pass provision_method through to compute resources properly so they don't need to guess
Dominic | (or use two separate methods, instead of create_vm for everything