kubevirt addon: use KubeVirt CR instead of deprecated ConfigMap

[zcahana]

Modify the kubevirt addon (#8275) to configure KubeVirt via its operator's custom resource (KubeVirt), instead of via the deprecated (and soon sometime to be removed) kubevirt-config ConfigMap.

Also slight changes to the saved manifest file names (avoid confusing renames).

[k8s-ci-robot]

Hi @zcahana. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[minikube-bot]

Can one of the admins verify this patch?

[zcahana]

/cc @medyagh since you reviewed #8275, maybe you can take a look at this too? thanks! 😄

[medyagh]

@zcahana do u mind sharing Before and After this PR with an example and output ?

[zcahana]

Well, the usage and the output of the addon enablement command hasn't changed:

zvic@ZVICAHANA-D2LK:~/Workspace/minikube (kubevirt_configmap)$ ./out/minikube addons enable kubevirt
    ▪ Using image bitnami/kubectl:1.17
🌟  The 'kubevirt' addon is enabled

Semantically, both before and after, we have a functional kubevirt installation.

Internally, there are some differences (which also affect users who wish to tinker with KubeVirt configuration):

• Before, there's been both a KubeVirt CR as well as a kubevirt-config ConfigMap, whereas the ConfigMap takes precedence over anything specified in the KubeVirt.spec.configuration field.
• After, there's no kubevirt-config ConfigMap created at all, and the KubeVirt.spec.configuration.developerConfiguration.useEmulation field is set to true. All other configuration should go into KubeVirt.spec.configuration as well.

[rmohr]

This definitely works, but in general our kubevirt-cr.yaml does not set any non-default option and for declarative kubevirt installs with kubevirt you can just apply such a cr:

apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
  namespace: kubevirt
spec: {}

Or in your case:

apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
  namespace: kubevirt
spec:
  developerConfiguration:
    useEmulation: true

So in stead of

curl -sL "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-cr.yaml" -o /manifests/kubevirt-cr.yaml

just directly write the above content and you don't need to deal with patches or anything (and that is a feature and not a works-by-accident flow :) ).

[zcahana]

Updated accordingly.

Note that I too prefer the cat << EOF | kubectl apply -f - syntax, but this doesn't work in this context since the above pod.yaml.tmpl template is rendered using the html/template pkg, which doesn't like the <<.

[rmohr]

Looks great, at least for me.

[medyagh]

Thank you

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: medyagh, rmohr, zcahana

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [medyagh]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment