Problem
The network.driver HW constraint (used to request a guest with a specific NIC kernel driver, e.g. ice, mlx5_core, i40e) is defined in the tmt hardware spec and works with the Artemis provision plugin, but the Beaker provision plugin (tmt/steps/provision/mrack.py) has no transformer registered for it.
In tmt/steps/provision/mrack.py, _CONSTRAINT_TRANSFORMERS includes transformers for related constraints such as device.driver (mapped to Beaker's MODULE key-value filter via _transform_device_driver) and disk.driver (mapped to BOOTDISK via _transform_disk_driver), but there is no _transform_network_driver. As a result, constraint_to_beaker_filter() falls through to _translate_constraint_by_transformer() returning _transform_unsupported(), which silently produces an empty filter. The only observable effect is a warning:
Hardware requirement 'network.driver' will have no effect.
Provisioning then proceeds without filtering on NIC driver, i.e. Beaker can hand back a host with the wrong network hardware and the plan continues rather than failing loudly.
Impact
Networking QE (rhel-net-hwe / KNQE) tests almost exclusively target real physical NICs (bonding, VLAN, SR-IOV, traffic generation, etc.) and therefore must run on the Beaker (bare-metal) backend rather than Artemis (cloud/VM). Without network.driver support in the Beaker plugin, there is no way to reliably select a host with the required NIC hardware for these tests.
Suggested fix
Add a _transform_network_driver transformer (mirroring _transform_device_driver / _transform_disk_driver) that maps network.driver to the appropriate Beaker hostRequires filter (e.g. a MODULE key-value filter scoped to network devices, or Beaker's Devices element as used by device.driver), so network.driver constraints are actually forwarded to Beaker instead of being dropped.
References
- Reported via https://redhat.atlassian.net/browse/TFT-5027 (Gap 1 of 2 — the same issue also covers same-switch host pairing for multihost jobs, tracked separately)
tmt/steps/provision/mrack.py: _transform_device_driver, _transform_disk_driver, _translate_constraint_by_transformer, _transform_unsupported
Problem
The
network.driverHW constraint (used to request a guest with a specific NIC kernel driver, e.g.ice,mlx5_core,i40e) is defined in the tmt hardware spec and works with the Artemis provision plugin, but the Beaker provision plugin (tmt/steps/provision/mrack.py) has no transformer registered for it.In
tmt/steps/provision/mrack.py,_CONSTRAINT_TRANSFORMERSincludes transformers for related constraints such asdevice.driver(mapped to Beaker'sMODULEkey-value filter via_transform_device_driver) anddisk.driver(mapped toBOOTDISKvia_transform_disk_driver), but there is no_transform_network_driver. As a result,constraint_to_beaker_filter()falls through to_translate_constraint_by_transformer()returning_transform_unsupported(), which silently produces an empty filter. The only observable effect is a warning:Provisioning then proceeds without filtering on NIC driver, i.e. Beaker can hand back a host with the wrong network hardware and the plan continues rather than failing loudly.
Impact
Networking QE (rhel-net-hwe / KNQE) tests almost exclusively target real physical NICs (bonding, VLAN, SR-IOV, traffic generation, etc.) and therefore must run on the Beaker (bare-metal) backend rather than Artemis (cloud/VM). Without
network.driversupport in the Beaker plugin, there is no way to reliably select a host with the required NIC hardware for these tests.Suggested fix
Add a
_transform_network_drivertransformer (mirroring_transform_device_driver/_transform_disk_driver) that mapsnetwork.driverto the appropriate BeakerhostRequiresfilter (e.g. aMODULEkey-value filter scoped to network devices, or Beaker'sDeviceselement as used bydevice.driver), sonetwork.driverconstraints are actually forwarded to Beaker instead of being dropped.References
tmt/steps/provision/mrack.py:_transform_device_driver,_transform_disk_driver,_translate_constraint_by_transformer,_transform_unsupported