Bug 1388147

Upstream bug component is Hosts

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.

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.

Maybe I should add this causes issues in VMWare environment, does it change your statements above, Marek?

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?

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.

Upstream bug assigned to mhulan

Upstream bug assigned to mhulan

Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16782 has been resolved.

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

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
ab4159467777852f63b012eb79dbadbe
- wget -q -O /dev/null --no-check-certificate http://192.168.121.206/unattended/built?token=9ada72b7-c55b-4734-a676-6ea5620c25c9
- md5sum /var/lib/tftpboot/pxelinux.cfg/01-52-54-00-95-6f-5f
2836bcae24d02f2508681fc6396599c4
- the pxe file contains localboot menu

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