Bug 1684170

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.