Description of problem: Even if the Provision was not selected when creating a host, Foreman takes it positive all the time, causing all VMs to boot from the PXE Version-Release number of selected component (if applicable): current master How reproducible: Steps to Reproduce: 1.Go to provision a host without selecting the provision option 2. 3. Actual results: Always sends provision=1, causing booting error for all VMs Expected results: Should send boot order correctly Additional info:
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