Add UEFI HTTP Boot provisioning test

[shubhamsg199]

Adding UEFI HTTP Boot provisioning test. The test will be skipped till the BZ#2242925 is fixed

[jyejare]

ACK, looks good!

Could we please run PRT if possible for provisioning!

[Gauravtalreja1]

Ack, great job @shubhamsg199

@jyejare PRT will skip this tests as he's using pytest.mark.skip_if_open("BZ:2242925")

[rplevka]

I see no assertions that would test that the host is indeed being provisioned by HTTPBoot.
Satellite used to deploy the pxelinux and grub config files along the others no matter what kind of OS bootloader you selected. So I am wondering whether the host is indeed using the HTTPBoot here and not just falling back to any other method.
This test does not do any kind of introspection into the boot and installer procedures at all and simply blindly waits till the host build status is being flipped in satellite.
I'd personally expect more assertions especially in this area as there are several points where the provisioning might go wrong (invalid provisoning token being passed, proxy not reachable, rendered template being wrong,...).
Having a failed test of this kind, not knowing what happened sounds non-optimal to me.

I'd suggest to add some checkpoints, like listening to incoming HTTP requests to the HTTP proxy to ensure, that a correct request indeed arrived and that the proxy correctly responded to it.
We could as well issue the call to proxy manually and see if we get the properly rendered template with the given provisioning token (at least just log it or save it as an artifact for the eventual TFA).

Thoughts?

[shubhamsg199]

I see no assertions that would test that the host is indeed being provisioned by HTTPBoot. Satellite used to deploy the pxelinux and grub config files along the others no matter what kind of OS bootloader you selected. So I am wondering whether the host is indeed using the HTTPBoot here and not just falling back to any other method. This test does not do any kind of introspection into the boot and installer procedures at all and simply blindly waits till the host build status is being flipped in satellite. I'd personally expect more assertions especially in this area as there are several points where the provisioning might go wrong (invalid provisoning token being passed, proxy not reachable, rendered template being wrong,...). Having a failed test of this kind, not knowing what happened sounds non-optimal to me.

I'd suggest to add some checkpoints, like listening to incoming HTTP requests to the HTTP proxy to ensure, that a correct request indeed arrived and that the proxy correctly responded to it. We could as well issue the call to proxy manually and see if we get the properly rendered template with the given provisioning token (at least just log it or save it as an artifact for the eventual TFA).

Thoughts?

If we select Grub2 UEFI HTTP as pxe loader, the booting always starts with PXE over ipv4 then ipv6 and then over HTTP ipv4 and ipv6. However, PXE over ipv4 tries to download the grubx64.efi file but it fails, so I guess the Bootloader here matters.
I'll try to implement some functions maybe to read logs to verify the HTTP requests(similar to what we have in discovery tests)

[rplevka]

thanks for implementing it.
there are few more log patterns you might test down the road, e.g. request for the ks file, etc. but i am not going to block the PR on this.

thank you