Bug 2016717

Summary: Virtual NIC naming conventions expected by fact_parser.rb cause registrations to fail
Product: Red Hat Satellite Reporter: Pablo Hess <phess>
Component: RegistrationAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED NOTABUG QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.9.0CC: bbuckingham, lstejska, myoder, nalfassi, rlavi, saydas
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-16 08:15:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pablo Hess 2021-10-22 21:50:31 UTC 
Description of problem:
When registering a host with virtual NICs that do not follow the most common NIC naming patterns, host registration with `subscription-manager` fails to parse NIC facts and results in 422 Unprocesable Entity error by foreman.

Version-Release number of selected component (if applicable):
foreman-2.3.1.24-1.el7sat.noarch

How reproducible:
Every time given the "right" conditions i.e. the "right" NIC names on a host.

Steps to Reproduce:
1. Have a host with a bridge named something other than br0, br1, etc. E.g. my-br.
2. Add a VLAN-tagged vNIC to this host, e.g. my-br.42.
3. Try to register this host to Satellite with `subscription-manager register`.

Actual results:
Registration fails and the client receives an error message:
"HTTP error (422 - Unknown): Validation failed: Attached to can't be blank" 

Expected results:
Registration would succeed.


Additional info:

Satellite logs this to production.log while processing the NIC::Managed events:

2021-10-15T10:18:44 [E|kat|a0a5a5bf] <Class> ActiveRecord::RecordInvalid
2021-10-15T10:18:44 [E|kat|a0a5a5bf] attached_to: ["can't be blank"]
2021-10-15T10:18:44 [I|app|a0a5a5bf] Completed 422 Unprocessable Entity in 13967ms (Views: 0.2ms | ActiveRecord: 3529.9ms | Allocations: 2509109)

If I rename the bridge from `my-br` to e.g. `br2` and the respective VLAN-tagged vNIC from `my-br.42` to `br2.42` then the registration succeeds.


I've investigated the issue and the problem is in the regexes used to identify virtual interfaces while foreman tries to locate the physical interface to mark as primary for the newly-registered host. I have a PR ready and will be submitting it soon and linking it here.
Comment 1 Pablo Hess 2021-10-22 22:11:57 UTC 
PR is added to the Foreman issue tracker bug linked here.

https://projects.theforeman.org/issues/33771
Comment 4 Leos Stejskal 2022-06-16 12:19:58 UTC 
Hi Pablo,
upstream PR [0] have been closed with the proposal from lzap [1] to fix the Facter reporting instead of changing the regex parsing in the Foreman.
Are there any updates about the fix?

[0] https://github.com/theforeman/foreman/pull/8867
[1] https://github.com/theforeman/foreman/pull/8867#issuecomment-1018267088
Comment 6 Leos Stejskal 2023-01-30 08:08:34 UTC 
Hi,
in that case I suggest close the BZ as not a bug, as for the comment [0] in github:

> I think if this is causing any pains, the proper solution is to make contribution into Facter so it actually reports some usable information from linux netlink kernel API - e.g. interface types and relationship (master-slave).
> Then we could utilize it in Foreman and avoid "guessing".
Comment 7 Red Hat Bugzilla 2023-09-18 04:27:25 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days