Description of problem: I got into a situation where kubevirt-ansible wasnt updated with latest kubvirt releases (so it was on 0.6 by default) and while the kubevirt apb got version 0.7.0-alpha.2, i ended up with a mismatch (in this specific case crds were ovm & vm, instead of vm & vmi) Version-Release number of selected component (if applicable): 0.7.0-alpha.2 How reproducible: 100% Steps to Reproduce: 1. deploy latest kubevirt apb, while kubevirt-ansible as an old version 2. 3. Actual results: a mismatch of versions Expected results: i would expect the apb to be able to set the version when calling the provisioning playbook in kubevirt-ansible Additional info: Ryan already started looking at it, and said that the command being run is 'ansible-playbook -i /etc/ansible/hosts playbooks/provision.yml -e kubevirt_version='0.7.0-alpha.2' ....'. Those vars should be getting to the kubevirt-ansible tasks.
Nelly, I'm just starting to have a look to it, I think it'd be a matter of making kubevirt-apb to pass the version that it gets from user (or the default value) down to kubevirt-ansible. Going to test: https://github.com/tripledes/kubevirt-apb/commit/5637d63176fceea2198895b881fb4a491b2f57c2 that and will report back ASAP.
PR sent: * https://github.com/ansibleplaybookbundle/kubevirt-apb/pull/74 After applying the PR, the images pulled are the correct ones, e.g. using version 0.6.0 on the APB form results in the correct images being pulled and started: docker.io/kubevirt/virt-api v0.6.0 d27daff06b15 3 weeks ago docker.io/kubevirt/virt-handler v0.6.0 27449e9e6655 3 weeks ago docker.io/kubevirt/virt-controller v0.6.0 b7849a90761c 3 weeks ago
The PR was merged.
As the PR was already merged, I was wondering: @Lukas, do you need to test anything? @Nelly, do you still see the reported issue?
I am trying to verify this bug, but I am hitting new issue https://bugzilla.redhat.com/show_bug.cgi?id=1614322 .
I am not sure how to verify this bug at the moment. It seems to be u/s issue - I don't remember if we were able to reproduce it on d/s. We don't pass `kubevirt_version` parameter to d/s APB, we use docker_tag & registry_url & registry_namespace instead. So I can do verification with u/s APB if you like - that means it is not 1.2 version as it is targeted in this bug. Any thoughts ?
yes, i believe the only way to verify it is to try and pass in the u/s APB a version which is not updated in kubevirt-ansible (v0.9 for example) and make sure that the APB calls kubevirt-ansible with the version param
I gave a try and failed with other issue, it seems that u/s apb is broken. Or interface was changed. [root@cnv-executor-lbednar-master1 ~]# oc get clusterserviceclass -o custom-columns=Name:spec.externalName,externalID:spec.externalID,Broker:spec.clusterServiceBrokerName Name externalID Broker dockerhub-virtualization 034b5848406905aea463db2ec2e6d876 ansible-service-broker [root@cnv-executor-lbednar-master1 ~]# cat kubevirt-apb-us.yml --- apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: kubevirt namespace: kube-system spec: clusterServiceClassExternalName: dockerhub-virtualization clusterServicePlanExternalName: default parameters: admin_user: test_admin admin_password: 123456 version: "0.9.0" oc create -f kubevirt-apb-us.yml [root@cnv-executor-lbednar-master1 ~]# oc logs -n dockerhub-virtualization-prov-td669 bundle-a92c85ef-85c0-4991-81da-8452714746f1 TASK [kubevirt : Render KubeVirt Yaml] ***************************************** fatal: [localhost]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'image_pull_policy' is undefined"} PLAY RECAP ********************************************************************* localhost : ok=8 changed=5 unreachable=0 failed=1
https://github.com/kubevirt/kubevirt-ansible/pull/407 will fix latest.
Sergi please fill in the "Fixed In Version" field.
Federico, added 1.3 (current target), not sure what version was it, moved on to supportability team and lost track of this bug.
This bug is an upstream bug, i was unable to verify it in this version timeframe and it will become irrelevant in the next version closing as upstream