Bug 1367549 - When a Discovered Host is converted to a Managed Host the IP address is not changed to fall within the subnet range
Summary: When a Discovered Host is converted to a Managed Host the IP address is not c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Discovery Plugin
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: 6.7.0
Assignee: Lukas Zapletal
QA Contact: Jitendra Yejare
URL: http://projects.theforeman.org/issues...
Whiteboard:
: 1724214 (view as bug list)
Depends On:
Blocks: rhci-common-installer 1361332
TreeView+ depends on / blocked
 
Reported: 2016-08-16 17:56 UTC by Jason Montleon
Modified: 2020-04-14 13:22 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 13:22:16 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 16143 Urgent Closed Discovered host IP address is not changed to fall within the subnet range 2020-09-17 18:50:45 UTC
Red Hat Bugzilla 1361332 unspecified CLOSED Hypervisor host fails to convert to managed host during RHEV deployment 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHSA-2020:1454 None None None 2020-04-14 13:22:44 UTC

Internal Links: 1361332

Description Jason Montleon 2016-08-16 17:56:41 UTC
When booting a host for discovery my understanding is it is using an address from the pool configured in the /etc/dhcp/dhcpd.conf.

When converting the host to discovered though the address is not changed to fall within the range specified for the subnet.

This can lead to conflicts with later discovered hosts having the same IP address specified as an existing host record does.

Comment 6 Bryan Kearney 2017-03-14 17:25:38 UTC
An upstream issue has been opened for this. When this is fixed, the next version of satellite will contain the fix. We will no longer be tracking this downstream. If you feel this was closed in error, please feel free to re-open with additional information.

Comment 7 Bryan Kearney 2017-03-14 17:26:00 UTC
An upstream issue has been opened for this. When this is fixed, the next version of satellite will contain the fix. We will no longer be tracking this downstream. If you feel this was closed in error, please feel free to re-open with additional information.

Comment 8 Lukas Zapletal 2019-06-28 08:43:42 UTC
*** Bug 1724214 has been marked as a duplicate of this bug. ***

Comment 9 Lukas Zapletal 2019-06-28 08:47:55 UTC
Still a valid bug. Lemme take a look if I can do something today.

Comment 10 Bryan Kearney 2019-09-12 16:03:44 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/16143 has been resolved.

Comment 11 Jitendra Yejare 2020-01-30 10:36:25 UTC
Tried verifying this using Libvirt Host discovery:

Steps:
----------------
1. Set IP range (let's say 10 to 100) in satellite dcpd.conf
2. Create Subnet with different IP range in Satellite with different IP range (lets say 102 to 254)
3. Setup Discovery on satellite 
4. PXE Boot internal libvirt VM.
5. Verify the VM is Discovered.
6. Then go to Libvirt Compute Resource, and import the Discovery VM as managed.

Observation:
-----------------
1. The VM is being discovered in satellite with IP provided in dhcpd.conf range.
2. The new IP from satellite subnet range has been assigned to the VM on importing that VM as managed.
3. The host is successfully imported as managed.
4. On importing the host, the orchestration steps are 'not running' on Discovered host. The host is still showing Success Discovery window.
5. The discovered host, inside Host -> Discovered Host is not deleted post imported it as managed host.
6. The new(satellite subnet) assigned IP to the managed VM is not pingable instead the old(dhcpd.conf) is pingable.


NeedInfo:
------------------
1. I think the first 3 observations are good and as expected.
2. But below 4,5 and 6 seems to be not behaving as per expectation. I believe the managed host should run the orchestration steps, the discovered host should be removed from UI and the new IP should be pingable and assigned to VM.

Comment 12 Lukas Zapletal 2020-01-30 17:04:49 UTC
Hey,

> 6. Then go to Libvirt Compute Resource, and import the Discovery VM as managed.

this is incorrect interpretation of the workflow. By "converting to discovery", the reporter meant when a discovered host is submitted for provisioning, thus "converted" to managed host. This is an internal term we use in the code, but it is also a term to "turn an unmanaged host to managed" which is a rarely used feature which is not in the scope of this BZ.

So simply just verify the host during provisioning gets an IP address that is from the defined subnet range (must be different than IP lease it was discovered with if the lease pool is out of the range).

Comment 13 Jitendra Yejare 2020-02-10 11:55:46 UTC
Verified!

Steps:
----------------
Same as comment 11 but Step 6 is replaced with what's said in comment 12.


Observation:
---------------
1. The VM is being discovered in satellite with IP provided in dhcpd.conf range.
2. The new IP from the satellite subnet range has been assigned to the VM provisioning the discovered host(aka importing as managed, and by assigning the hostgroup).
3. The host is successfully provisioned.
Status 	OK
Build 	Pending installation
4. On importing the host as managed, the orchestration steps are 'running' on the Discovered host. The host was showing the installation of packages.
5. The discovered host, inside Host -> Discovered Host is deleted post provisioning.
6. The new(satellite subnet) assigned IP to the managed VM is pingable instead of the old(dhcpd.conf).

------------- After Discovery and before Provisioning:--------------------
# ping 192.168.100.13
PING 192.168.100.13 (192.168.100.13) 56(84) bytes of data.
64 bytes from 192.168.100.13: icmp_seq=1 ttl=64 time=0.750 ms
64 bytes from 192.168.100.13: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 192.168.100.13: icmp_seq=3 ttl=64 time=0.372 ms
^C
--- 192.168.100.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.372/0.507/0.750/0.172 ms


------------- After Provisioning--------------------
The old IP is not pinging.
# ping 192.168.100.13
PING 192.168.100.13 (192.168.100.13) 56(84) bytes of data.
^C
--- 192.168.100.13 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

Instead the new IP is pining.
# ping 192.168.100.209
PING 192.168.100.209 (192.168.100.209) 56(84) bytes of data.
64 bytes from 192.168.100.209: icmp_seq=1 ttl=64 time=0.509 ms
64 bytes from 192.168.100.209: icmp_seq=2 ttl=64 time=0.207 ms
64 bytes from 192.168.100.209: icmp_seq=3 ttl=64 time=0.253 ms
64 bytes from 192.168.100.209: icmp_seq=4 ttl=64 time=0.301 ms
64 bytes from 192.168.100.209: icmp_seq=5 ttl=64 time=0.660 ms
^C
--- 192.168.100.209 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.207/0.386/0.660/0.171 ms

Comment 14 Lukas Zapletal 2020-02-10 13:15:12 UTC
I had a request in my INBOX to review this BZ but I don't see any NEEDINFO set on this one. Just saying for the record.

Comment 17 errata-xmlrpc 2020-04-14 13:22:16 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.