Description¶

When registering an existing host via Global Registration using a hostgroup that includes a Compute Resource, core Foreman's compute orchestration methods setCompute and delCompute are executed even though the host is unmanaged (managed: false).

The queue_compute method in app/models/concerns/orchestration/compute.rb adds orchestration tasks whenever compute_resource_id is present (inherited from the hostgroup), but does not check whether the host is actually managed before queuing compute operations.

Steps to reproduce¶

1. Create a hostgroup associated with a Compute Resource (e.g. Proxmox, libvirt, VMware)
2. Use Global Registration to register an existing (already running) host with that hostgroup
3. The host is created as managed: false, but setCompute still runs and attempts to create a compute instance
4. When setCompute fails, the rollback calls delCompute, which also fails trying to destroy a non-existent VM

Expected behavior¶

setCompute and delCompute should return early (return true) when the host is not managed, similar to how setComputeIP and setComputeIPAM already do.

Actual behavior¶

setCompute tries to call compute_resource.create_vm for an unmanaged host, fails, then delCompute tries to call compute_resource.destroy_vm, causing the host registration to fail with orchestration errors.

Root cause¶

In app/models/concerns/orchestration/compute.rb, the methods setCompute (line ~139) and delCompute (line ~226) lack a managed? guard. Other methods in the same file like setComputeIP and setComputeIPAM already have return true unless managed? — but setCompute and delCompute do not.

Suggested fix¶

Add return true unless managed? at the beginning of both setCompute and delCompute methods in app/models/concerns/orchestration/compute.rb.

Environment¶

• Foreman 3.19 (also reproducible on 3.x series)
• Any compute resource plugin (tested with foreman_fog_proxmox 0.21.0)

Related¶

• Plugin-side fix: https://github.com/theforeman/foreman_fog_proxmox/pull/456