sap_hypervisor_node_preconfigure/kubevirt_vm: Fix installation of CNV operator

[newkit]

Changed order of CNV HyperConverged instance creation and changed webhook endpoint name waiting.

This fixes issue 146 by adding more conditionals that have to be true when waiting for webhook endpoint in order to continue.

[marcelmamula]

@newkit This PR does not fix #146

It just moves webhook wait into task file created in previous PR, it does not change any order.

[newkit]

@newkit This PR does not fix #146

It just moves webhook wait into task file created in previous PR, it does not change any order.

@marcelmamula
Well, it does fix #146 since it adds more conditionals waiting for the webhook endpoint to be ready:

until: - __sap_hypervisor_node_preconfigure_register_webhook_check is defined - __sap_hypervisor_node_preconfigure_register_webhook_check.resources | length > 0 - __sap_hypervisor_node_preconfigure_register_webhook_check.resources[0].subsets is defined - __sap_hypervisor_node_preconfigure_register_webhook_check.resources[0].subsets | length > 0 - __sap_hypervisor_node_preconfigure_register_webhook_check.resources[0].subsets[0].addresses is defined - __sap_hypervisor_node_preconfigure_register_webhook_check.resources[0].subsets[0].addresses | length > 0

vs. before

until: webhook_service.resources | default([]) | length > 0

[marcelmamula]

@newkit Issue you mentioned says order:

With the latest addition of waiting for the CNV webhook endpoint, the order is wrong.
First, we need to create the CNV HyperConverged instance and then wait for the endpoint.

This PR enhances until conditional as you said, but it does not change any order. All I am asking is that you ensure that Issue description is clear enough so this PR can be logically linked to it, because this is what I see now:

• Issue: Order problem between instance and webhook.
• PR: Replace task with previously added reusable task file with better conditionals. No changes to order.

[newkit]

@marcelmamula Yes. you are absolutely right, the issue was mentioning the order which I believed would be the root cause when I opened the bug. But it turned out it's the conditionals that weren't fully reflecting the readyness of the webhook endpoint. I've edited the issue so that it's in line now with this PR.

[marcelmamula]

LGTM