Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1701075 - Subnet is blank after provisioning a discovered host via customize Host form
Summary: Subnet is blank after provisioning a discovered host via customize Host form
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Discovery Image
Version: 6.4.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: 6.9.0
Assignee: Lukas Zapletal
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-18 00:19 UTC by Jayant Bhatia
Modified: 2024-06-13 22:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1933163 (view as bug list)
Environment:
Last Closed: 2021-04-21 13:11:48 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 29221 0 Normal Closed Subnet is blank after provisioning a discovered host 2021-02-18 02:55:17 UTC
Red Hat Product Errata RHSA-2021:1313 0 None None None 2021-04-21 13:12:11 UTC

Description Jayant Bhatia 2019-04-18 00:19:05 UTC 
Description of problem:

A subnet is not assigned to the discovered host automatically while using foreman discovery image method during provisioning.

Version-Release number of selected component (if applicable):

Satellite-6.4.2

How reproducible:

1) Boot a new machine using Foreman Discovery Image ISO on target host machine.
2) Select to discover with DHCP
3) Enter the Satellite server URL, specifying port 443 and selecting "server" option
4) Upon "success" message for Discovery Status, move to Satellite GUI.
5) Navigate to Satellite WebUI -> Hosts -> Discovered Hosts 
6) The 'Subnet' column shows that a subnet has been automatically assigned to the discovered host.
7) Click on Provision -> Select Hostgroup -> Customize Host ->  Interface tab.

Actual results:
There is no subnet assigned to the discovered host.

Expected results:
The subnet should be automatically assigned to the discovered host.

Additional info:
Note: The same is working as expected in Satellite-6.3 and issue is observed only in Satellite-6.4.
Comment 6 Lukas Zapletal 2019-04-24 13:22:34 UTC 
This works for me on 6.5, need to try on 6.4. We haven't changed any behavior for 6.4 in this regard, Satellite Server will try to find and match subnet reported by the discovered host as primary/provisioning IP address just as 6.3 did. When found, subnet is associated to the host and all communication goes through Discovery Capsule associated with the subnet. Then the Customize host works as well.

Can you check taxonomy of your Subnet and Host? Paste screens of Host Organization and Location and then Subnet Org/Loc.
Comment 7 Lukas Zapletal 2019-04-24 13:33:33 UTC 
I just tested this on 6.4. Make sure that the HOSTGROUP taxonomy matches SUBNET taxonomy.
Comment 8 roarora 2019-08-21 15:34:04 UTC 
Reopening the bug as another customer is hitting this. I checked the taxonomy for hostgroup and subnet and its good.

In discovered hosts page, subnet is detected fine but when provisioned and customized, the subnet is not there in the interface. This leads to failed kickstart fetch during build.
Comment 11 Lukas Zapletal 2019-08-22 08:08:55 UTC 
Let me explain one important aspect of discovery.

When a host is discovered in subnet A and then a hostgroup with subnet B is selected, provisioning will not work unless Customize Host button is pressed and IP address is updated (e.g. via Suggest new link) to match the selected Subnet from the hostgroup. Otherwise provisioning will fail with "IP does not match selected subnet". We are tracking a feature request to support this: https://github.com/theforeman/foreman_discovery/pull/306

Please provide reproducer because it works for me.
Comment 13 rhituser 2020-02-27 18:12:46 UTC 
This is still an issue on 6.6.1.  This issue has been experienced since upgrading to Satellite 6.4.  There is no subnet defined in the host group to which a discovered host is assigned when this has been known to occur.  The host on the Discovered Hosts page correctly shows the detected subnet, but when navigating to its interface during its customization, this IPv4 Subnet is not selected (no value is selected).  If forgotten or otherwise not manually set, the provisioning process will fail.
Comment 14 Lukas Zapletal 2020-02-28 09:52:08 UTC 
Hello,

only hostgroups with domain/subnet set can be used for discovery provisioning. The subnet for discovered hosts is not subnet that host should be provisioned in. It only helps to pick Discovery Capsule to use to proxy HTTPS requests when talking to discovered hosts. I will implement a warning or even hide hostgoups which has subnet set to blank to prevent confusion. This cannot be a regression, this has never worked a different way. You likely had a hostgroup which had domain/subnet set in the past.

Anyway, it's a natural expectation to assume that subnet should carry over to provisioning phase, let's change this behavior. I have implemented this upstream, due to dependency on other rather big change (unused IP call during provisioning) this cannot be backported tho, will be part of future Satellite release.
Comment 15 rhituser 2020-02-28 12:04:35 UTC 
The host group configuration has not changed with regard to the domain/subnet configurations in our environment and the functionality DID change starting with version 6.4 of Satellite and has stopped working as it used to since.
Comment 17 Lukas Zapletal 2020-03-02 08:40:20 UTC 
Let me change my statement to: if a hostgroup is selected and it has no subnet set, the discovered subnet did not carry over. However when provisioning was done without any hostgroup it did carry over. This is how I read the code today.

Anyway, I have fixed this and the patch is now pending review. Once merged, we can ask backport into 6.7.

WORKAROUND HOTFIX: Apply this change to https://github.com/theforeman/foreman_discovery/pull/495/files#diff-0e08314173f533a2b6e73218bc5d4b10 to app/controllers/discovered_hosts_controller.rb file and restart httpd.
Comment 18 Bryan Kearney 2020-09-10 12:04:24 UTC 
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/29221 has been resolved.
Comment 19 Brad Buckingham 2020-11-13 19:36:24 UTC 
Fix is in Satellite 6.9 SNAP 1 with tfm-rubygem-foreman_discovery-16.3.1-1.el7sat.noarch
Comment 20 Roman Plevka 2021-01-07 15:21:57 UTC 
VERIFIED
on sat6.9.0-8.0

the subnet of the automatically discovered host is reported correctly and the same subnet is pre-selected in the customize host dialog during host provisioning
Comment 23 errata-xmlrpc 2021-04-21 13:11:48 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 (Moderate: Satellite 6.9 Release), 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-2021:1313
Note You need to log in before you can comment on or make changes to this bug.