Created attachment 1539568 [details] foreman-tail.log Description of problem: If user will try to use custom installation media (created by him and he has it accessible on webserve) he can provision discovered host without any issue. Problem is that the common way how to provision a host from satellite is via synced installation medium from CDN (repository rhel-7-server-kickstart) which will provide necessary images to deploy RHEL on the host. Manual provision from Satellite works. Version-Release number of selected component (if applicable): Satellite 6.4.2 (installed from CDN) tfm-rubygem-ovirt_provision_plugin-2.0.3-1.el7sat.noarch ovirt-engine-4.2.8.3-0.1.el7ev.noarch (synced from CDN) How reproducible: always Steps to Reproduce: 1. Synchronize repositories for RHV and RHEL (also with rhel-7-server-kickstart) 2. Check operating system in host group, there should be as "Synced Content": "Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.6" 3. try to provision with this hostgroup Actual results: it will fail - attached foreman logs Expected results: should provision discovered host
I think there could be two scenarios based on differences between "medium_id"=>"" and "medium_id"=>"0" (which I provided in the bug) In first case: "medium_id"=>"" I didn't create any custom installation media on the Satellite server and I used only the synchronized one. It could lead to different message about non-existing installation media In second case: "medium_id"=>"0" I used in hostgroup operating system with custom installation media, so that value could be leftover after deletion of the media (id in foreman database starts from 1) in Satellite database. My steps were: sychnronized installation media from CDN, delete installation media, check hostgroup.
(In reply to Petr Kubica from comment #1) > I think there could be two scenarios based on differences between > "medium_id"=>"" and "medium_id"=>"0" (which I provided in the bug) > In first case: "medium_id"=>"" > I didn't create any custom installation media on the Satellite server and I > used only the synchronized one. It could lead to different message about > non-existing installation media > > In second case: "medium_id"=>"0" So it appears that 0 is invalid value to be sent by the ovirt-engine as part of the provision discovered host request. The media_id_seq which is the sequence for entries of the media table in 'foreman' db starts from 1. Therefore "0" should be an invalid value. Same goes for operating systems, architectures and other fields part of the host group. Where does the '0' arrive from when sending requests from RHV during provision of discovered host ? The answer is: https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/ExternalHostGroup.java#L18 The type of the properties is 'int' which its default is set to '0' when isn't set. We should replace 'int' with 'Integer' that reflects the actual value of the field and supports null/empty values. > I used in hostgroup operating system with custom installation media, so that > value could be leftover after deletion of the media (id in foreman database > starts from 1) in Satellite database. My steps were: sychnronized > installation media from CDN, delete installation media, check hostgroup.
With the proposed patch https://gerrit.ovirt.org/#/c/98195/ the parameters are being set according to their definition on the host group, also nested group is supported in this case: ESC[32m2019-05-16T09:16:25ESC[0m [ESC[32mIESC[0m|ESC[36mappESC[0m|30236926] Parameters: {"discovered_host"=>{"name"=>"macde00001122dd", "hostgroup_id"=>"28", "environment_id"=>"3", "mac"=>"de:00:00:11:22:dd", "domain_id"=>"1", "subnet_id"=>"2", "ip"=>"192.168.111.200", "architecture_id"=>"1", "operatingsystem_id"=>"4", "medium_id"=>"10", "ptable_id"=>"97", "puppet_proxy_id"=>"1", "root_pass"=>"[FILTERED]", "build"=>"true", "host_parameters_attributes"=>[{"name"=>"host_ovirt_id", "value"=>"[FILTERED]", "_destroy"=>"false"}, {"name"=>"compute_resource_id", "value"=>"[FILTERED]", "_destroy"=>"false"}, {"name"=>"pass", "value"=>"[FILTERED]", "_destroy"=>"false"}, {"name"=>"management", "value"=>"[FILTERED]", "_destroy"=>"false"}]}, "apiv"=>"v2", "id"=>"macde00001122dd"} Therefore if a nested host-group was selected, which inherits its attributes from the parent, they will not be specified in the request.
This bug fix is targeted to 4.3.5 but referenced patches are already included in 4.3.4. Can you please check and eventually adjust target milestone?
Verified in 4.3.4.3-0.1.el7
This bugzilla is included in oVirt 4.3.4 release, published on June 11th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.