Bug 1388147 - New host form network tab validations are broken
Summary: New host form network tab validations are broken
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Networking
Version: 6.2.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: Unspecified
Assignee: Marek Hulan
QA Contact: Tomas Strachota
Depends On: 1406362 1417075
TreeView+ depends on / blocked
Reported: 2016-10-24 15:10 UTC by Lukas Zapletal
Modified: 2020-06-11 13:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-02-21 16:51:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 16782 0 Normal Closed Different MAC addresses used in DHCP leases and TFTP when MAC address is set for libvirt VM 2020-03-30 10:36:40 UTC
Red Hat Bugzilla 1388104 0 high CLOSED TFTP "built" orchestration is skipped when there is an AR error 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 2874751 0 None None None 2017-02-22 06:55:37 UTC

Internal Links: 1388104

Description Lukas Zapletal 2016-10-24 15:10:10 UTC
With 6.2.2, it looks like I can create invalid hosts with:

A) two same MAC addresses
B) empty or same NIC identifiers

When I try to Edit Host and Submit it without any change, now validations trigger correctly. Looks like we need to execute those validations for new hosts as well as existing hosts.

Root cause: The New Host form submits and provisioning starts, but it fails to do "built" command and orchestration won't perform TFTP PXELinux template change due to ActiveRecord errors.

In the NIC codebase we have this remark:

# we can't use standard unique validation on interface since we can't properly handle :scope => :host_id
# for new hosts host_id does not exist at that moment, validation would work only for persisted records

Therefore it looks like this kind of validation (for new hosts) was done in JavaScript and there was a regression there.

Comment 4 Bryan Kearney 2016-10-25 08:20:23 UTC
Upstream bug component is Hosts

Comment 5 Marek Hulan 2016-11-03 14:54:42 UTC
There are couple of things here. I believe having empty identifier is valid except for vlan and alias. The identifier uniqueness is checked even for new hosts, see Host::Base#uniq_interfaces_identifiers it seems to work fine for me on Satellite 6.2.3 as well as on Foreman nightly. I wonder why you think we had some JS validations? 

We don't verify MAC address uniqueness in any version for new host and never did I believe. This validation is only on NIC side and should be probably moved to Host object too. From the case I assume you have a reproducer, could you please share it with me? If the MAC uniqueness is the source of the problem, a simple workaround is to don't use the same MAC for two interfaces so I'm lowering the priority.

Comment 6 Lukas Zapletal 2016-11-23 12:22:51 UTC
Marek, my reproducer is:

- deploy 6.2.x
- create new host with two NICs
- do not fill any NIC identifier (leave blank)
- submit
- md5sum of the PXELinux configuration of the provisioning NIC (MAC)
- make a fake curl call /built?token=XYZ
- md5sum of the PXELinux configuration of the provisioning NIC (MAC)

New content was not deployed for that host, I can still see the "Anaconda" PXELinux options while new "localboot" template should be deployed. Thank to the validation error (NIC ID already used) which is hidden somewhere in [sql] log the TFTP orchestration during "built" won't even start.

Comment 7 Lukas Zapletal 2016-12-13 15:09:07 UTC
Maybe I should add this causes issues in VMWare environment, does it change your statements above, Marek?

Comment 8 Marek Hulan 2016-12-22 09:40:18 UTC
Lukas, I think the part B) is solved by BZ 1406362. The MAC issue seems more complicated. When we provision on CR, even if user specifies desired MAC address, CR generates a random one and we update the interface with this new MAC. I think that's the case for all CR types.

I wonder what would be better, hide the MAC field for new hosts if the CR is not bare metal? But that should only apply for physical interfaces if we manage their DHCP and TFTP records, other types require it. Or should we add a validation only? Or should we make sure to ignore such error on later host save when it hits /built? after provisioning?

Comment 9 Marek Hulan 2016-12-22 11:48:08 UTC
The validation issue was caused by bug in orchestration. The DHCP record was created for old MAC that user specified in the form, while everything else used the new MAC fetched from compute resource. The proper fix is to reset the cached value once we get the MAC from compute resource.

I can see a potential confusion here, the field being displayed suggests that user could specify the MAC which would be used on CR. I added explanation in inline help next to MAC field as part of the fix. Specifying custom MAC would be a separate RFE, I don't think all CRs supports this though.

Comment 10 Bryan Kearney 2017-01-03 15:22:24 UTC
Upstream bug assigned to mhulan@redhat.com

Comment 11 Bryan Kearney 2017-01-03 15:22:28 UTC
Upstream bug assigned to mhulan@redhat.com

Comment 12 pm-sat@redhat.com 2017-01-09 15:03:11 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16782 has been resolved.

Comment 14 Oleksandr Shtaier 2017-08-01 07:29:16 UTC
Necessary help message is updated, but basically, no validation is required according to discussion in that BZ, so nothing significant to cover in test automation scripts

Comment 15 Tomas Strachota 2017-08-23 09:03:19 UTC
Verified. Version Tested: Satellite-6.3 Snap 10

Verification steps:
- created a host with custom MAC on libvirt
- the host received a new MAC from libvirt, foreman created correct pxe record
- md5sum /var/lib/tftpboot/pxelinux.cfg/01-52-54-00-95-6f-5f
- wget -q -O /dev/null --no-check-certificate
- md5sum /var/lib/tftpboot/pxelinux.cfg/01-52-54-00-95-6f-5f
- the pxe file contains localboot menu

Comment 16 pm-sat@redhat.com 2018-02-21 16:51:07 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-2018:0336

Note You need to log in before you can comment on or make changes to this bug.