Bug 1687341 - [Kubevirt-Foreman] Foreman always takes provision option true and gives bootorder 1
Summary: [Kubevirt-Foreman] Foreman always takes provision option true and gives booto...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Compute Resources - CNV
Version: 6.6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: 6.7.0
Assignee: Moti Asayag
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On: 1746434
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-11 10:35 UTC by Vatsal Parekh
Modified: 2020-04-14 13:24 UTC (History)
9 users (show)

Fixed In Version: tfm-rubygem-foreman_kubevirt-0.1.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 13:24:10 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github masayag foreman_kubevirt pull 61 None None None 2020-03-24 13:32:07 UTC
Red Hat Product Errata RHSA-2020:1454 None None None 2020-04-14 13:24:19 UTC

Description Vatsal Parekh 2019-03-11 10:35:39 UTC
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:

Comment 3 Moti Asayag 2019-04-07 08:27:21 UTC
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'.

Comment 4 Marek Hulan 2019-04-08 06:38:59 UTC
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.

Comment 5 Moti Asayag 2019-04-08 07:58:23 UTC
(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.

Comment 6 Marek Hulan 2019-04-08 11:49:44 UTC
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!

Comment 7 Vatsal Parekh 2019-04-12 06:58:01 UTC
This seems working on latest nightly Foreman + plugin master

Comment 10 Lukáš Hellebrandt 2020-03-24 13:31:42 UTC
Verified with Sat 6.7 snap 16. The interfaces are correctly marked as primary/provision, based on what is specified in WebUI.

Comment 13 errata-xmlrpc 2020-04-14 13:24:10 UTC
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


Note You need to log in before you can comment on or make changes to this bug.