update apiservice registration namespace and spec on initialization

[davidvossel]

related to #932

[rmohr]

In general great, we need that.

On second thought, we may need a check if there is another virt-api server running in the other namespace too and simply fail to start then. I think that otherwise the virt-api servers in different namespaces would just register themselves back and forth ...

@davidvossel what do you think?

[davidvossel]

@rmohr I updated this patch to fail early if a namespace mismatch occurs. This puts the resolution on the operator. The error message clearly states what the issue is and how to resolve it.

[rmohr]

s/apiservuce/apiservice

[davidvossel]

oops, fixed :)

[rmohr]

Looks perfect. Can go in as soon as the type is fixed and ci looks fine.

[cynepco3hahue]

retest this please

[rmohr]

@cynepco3hahue I think that something goes wrong during the aggregated apiserver registration.

[cynepco3hahue]

@rmohr Looks so, I see virt-api pod stuck

++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers
++ awk '!/virt-controller/ && /false/'
++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers
+ '[' -n 'false            virt-api-fd96f94b5-tjskr' ']'
+ echo 'Waiting for KubeVirt containers to become ready ...'
Waiting for KubeVirt containers to become ready ...
+ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers
+ awk '!/virt-controller/ && /false/'
+ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers
false            virt-api-fd96f94b5-tjskr

[rmohr]

Ok, it fails in a virt-api scale-out environment.

[rmohr]

Ha, now I see the issue. That should be:

if apiService.Spec.Service.Namespace  != namespace {

}

[davidvossel]

whoa, hooray for functional tests :)