Bug 1687341

This is a core issue, reproduced by running the following from rails console:

params = {"interfaces_attributes"=>{"0"=>{"ip"=>"192.168.111.196", "mac"=>"a2:a0:a2:a2:a2:c4", "provision"=>false}}}
host = Host.new(params)
puts host.interfaces.first.provision

the returned value is 'true'.

What is the expected behavior in this case? Every host we create needs to have one interface set as primary (chooses the FQDN) and provision (in case of network based provisioning, PXE booth happens on this interface). If you add more than one interface, you can choose the other interface as provisioning but it's mandatory to select one. In other compute resources this does not have effect on booting order, so I wonder why it has in kubevirt? Moving back before the problem is better understood, right now it does not seem as generic compute resource thing.

(In reply to Marek Hulan from comment #4)
> What is the expected behavior in this case? Every host we create needs to
> have one interface set as primary (chooses the FQDN) and provision (in case
> of network based provisioning, PXE booth happens on this interface). If you
> add more than one interface, you can choose the other interface as
> provisioning but it's mandatory to select one. In other compute resources
> this does not have effect on booting order, so I wonder why it has in
> kubevirt? Moving back before the problem is better understood, right now it
> does not seem as generic compute resource thing.

So If I get it right, in case I have only one interface, it will be checked both as primary and as provision.
and with more than one interfaces, you can set specific values as provided by the user:

params = {
  "interfaces_attributes" => { "0" => {"ip"=>"192.168.111.196", "mac"=>"a2:a0:a2:a2:a2:c4", "provision"=>false, "primary"=>true}, 
                               "1" => {"ip"=>"192.168.111.192", "mac"=>"a2:a0:a2:a2:a2:c3", "provision"=>true, "primary"=>false}
                             }
}

host = Host.new(params)
puts host.interfaces.first.primary # >>> true
puts host.interfaces.first.provision # >>> false

puts host.interfaces.second.primary # >>> false
puts host.interfaces.second.provision # >>> true

For CNV we set the boot order of the interface to be first if the interface was checked for 'provision'.
But if we unchecked it, for scenarios in which a disk was checked as the bootable device, the 'provision' would remain set.

We fixed this on the provider side and prefer boot from disk if selected than boot from interface.
But we assumed there is an issue with the core. Based on your explanation, there isn't and this is the expected one.
Thanks for clarifying. I'm moving this to POST with the PR that handled the boot order on the provider side.

Yes, you're correct. Other compute resources which allows setting up boot order usually only sets network as the first one. Once host calls back to Foreman and informs it's build, Foreman reconfigures boot menu on TFTP to boot local HDD. That way you can later rebuild the host but modifying the configuration again, since it still boots technically from the network. I know some people prefer to avoid net stack entirely and e.g. with vmware we're looking into giving user a chance to configure boot order explicitly. Seems you came to the same solution.

Thanks for explanation!

This seems working on latest nightly Foreman + plugin master

Verified with Sat 6.7 snap 16. The interfaces are correctly marked as primary/provision, based on what is specified in WebUI.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1454