metal3 - plain-http configuration broken in 0.9.0

[hardys]

#165 was a major update to the metal3 chart, and included a number of configuration changes to align us better with the upstream ironic-image.

The scenarios tested so far with TLS enabled (the default) work OK, but it's been noted that the configuration with auth/tls disabled is not working with the new chart version:

global:
  enable_basicAuth: false
  enable_tls: false
  enable_vmedia_tls: false
  ironicIP: 192.168.123.123
  provisioningInterface: eth0

The ironic container is restarting with errors like this, which I think is related to TLS being disabled:

::ffff:127.0.0.1 - - [25/Nov/2024 09:29:37] code 400, message Bad request syntax ('\\x16\\x03\\x01\\x02\\x00\\x01\\x00\\x01ü\\x03\\x03\\x8e\\x9f\\x87p·\\x14E')
::ffff:127.0.0.1 - - [25/Nov/2024 09:29:37] "\x16\x03\x01\x02\x00\x01\x00\x01ü\x03\x03\x8e\x9f\x87p·\x14E" 400 -
::ffff:127.0.0.1 - - [25/Nov/2024 09:29:37] code 400, message Bad request version ("\\x88kÎÃ\\x8eÅî?#óÉ`ÀæN¡ëéÉ\\x00H\\x13\\x02\\x13\\x03\\x13\\x01\\x13\\x04À,À0̨̩À\\xadÀ+À/À¬À#À'À")

Outside of developer scenarios I'm not sure we have any use-cases which require tls or auth to be disabled, but it would be good to fix this so previously working configurations do not fail.

In future we may want to consider deprecating/removing the enable_tls and enable_basicAuth values so we can limit the number of corner cases and focus on the production-ready configuration instead

Thanks to @ipetrov117 for spotting this issue!

[tmmorin]

We recently hit an issue with Lenovo servers for virtual media TLS (https://gitlab.com/sylva-projects/sylva-core/-/issues/2409).

Having the ability to effectively use enable_vmedia_tls: false would be a workaround for us.

So until a better solution is found for https://gitlab.com/sylva-projects/sylva-core/-/issues/2409, it would be nice if enable_vmedia_tls: false could be fixed.

(@lupescudaniel ^)

[lupescudaniel]

Usually me tests involved enable_tls and enable_vmedia_tls: false which was broken due to liveness and readiness, but as per indication I tested with enable_vmedia_tls: false.
Using this option, it worked , but I had to manually rollout the baremetal-operator pods using kubectl rollout -n metal3-system restart deployment baremetal-operator-controller-manager, to be able to update the configuration with the new updated configmap. After this the BMH entered inspection and the boot was done over http.