Description of problem: After deploying HCO, the following error appears in the kubevirt-ssp-operator log: Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\". Version-Release number of selected component (if applicable): erver Version: version.Info{GitVersion:"v0.18.1", GitCommit:"4913335bc20764d0d0bec55da00146887726ae15", GitTreeState:"clean", BuildDate:"2019-06-13T10:22:49Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} How reproducible: Steps to Reproduce: 1. Deploy HCO 0.18.1 2. Check for the kubevirt-ssp-operator logs Actual results: kubevirt-ssp-operator is faling Expected results: kubevirt-ssp-operator should start successfully Additional info: oc log kubevirt-ssp-operator-56566664dd-p2dmp kubevirt.io/rhel7.0: Red Hat Enterprise Linux 7.0\\n name.os.template.kubevirt.io/rhel7.1: Red Hat Enterprise Linux 7.1\\n name.os.template.kubevirt.io/rhel7.2: Red Hat Enterprise Linux 7.2\\n name.os.template.kubevirt.io/rhel7.3: Red Hat Enterprise Linux 7.3\\n name.os.template.kubevirt.io/rhel7.4: Red Hat Enterprise Linux 7.4\\n name.os.template.kubevirt.io/rhel7.5: Red Hat Enterprise Linux 7.5\\n name.os.template.kubevirt.io/rhel7.6: Red Hat Enterprise Linux 7.6\\n openshift.io/display-name: Red Hat Enterprise Linux 7.0+ VM\\n openshift.io/documentation-url: https://github.com/kubevirt/common-templates\\n openshift.io/provider-display-name: KubeVirt\\n openshift.io/support-url: https://github.com/kubevirt/common-templates/issues\\n tags: kubevirt,virtualmachine,linux,rhel\\n template.kubevirt.io/editable: '/objects[0].spec.template.spec.domain.cpu.sockets\\n\\n /objects[0].spec.template.spec.domain.cpu.cores\\n\\n /objects[0].spec.template.spec.domain.cpu.threads\\n\\n /objects[0].spec.template.spec.domain.resources.requests.memory\\n\\n /objects[0].spec.template.spec.domain.devices.disks\\n\\n /objects[0].spec.template.spec.volumes\\n\\n /objects[0].spec.template.spec.networks\\n\\n '\\n template.kubevirt.io/version: v1alpha1\\n template.openshift.io/bindable: 'false'\\n labels:\\n flavor.template.kubevirt.io/small: 'true'\\n os.template.kubevirt.io/rhel7.0: 'true'\\n os.template.kubevirt.io/rhel7.1: 'true'\\n os.template.kubevirt.io/rhel7.2: 'true'\\n os.template.kubevirt.io/rhel7.3: 'true'\\n os.template.kubevirt.io/rhel7.4: 'true'\\n os.template.kubevirt.io/rhel7.5: 'true'\\n os.template.kubevirt.io/rhel7.6: 'true'\\n template.kubevirt.io/type: base\\n workload.template.kubevirt.io/server: 'true'\\n name: rhel7-server-small\\nobjects:\\n- apiVersion: kubevirt.io/v1alpha3\\n kind: VirtualMachine\\n metadata:\\n labels:\\n app: ${NAME}\\n vm.kubevirt.io/template: rhel7-server-small\\n name: ${NAME}\\n spec:\\n running: false\\n template:\\n metadata:\\n labels:\\n kubevirt.io/domain: ${NAME}\\n kubevirt.io/size: small\\n spec:\\n domain:\\n cpu:\\n cores: 1\\n sockets: 1\\n threads: 1\\n devices:\\n disks:\\n - disk:\\n bus: virtio\\n name: rootdisk\\n - disk:\\n bus: virtio\\n name: cloudinitdisk\\n interfaces:\\n - bridge: {}\\n name: default\\n rng: {}\\n resources:\\n requests:\\n memory: 2G\\n networks:\\n - name: default\\n pod: {}\\n terminationGracePeriodSeconds: 0\\n volumes:\\n - name: rootdisk\\n persistentVolumeClaim:\\n claimName: ${PVCNAME}\\n - cloudInitNoCloud:\\n userData: '#cloud-config\\n\\n password: redhat\\n\\n chpasswd: { expire: False }'\\n name: cloudinitdisk\\nparameters:\\n- description: VM name\\n from: rhel7-[a-z0-9]{16}\\n generate: expression\\n name: NAME\\n- description: Name of the PVC with the disk image\\n name: PVCNAME\\n required: true\", \"msg\": \"Authentication or permission failure. In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \\\"/tmp\\\". Failed command was: ( umask 77 && mkdir -p \\\"` echo /.ansible/tmp/ansible-tmp-1563095866.35-35005751701263 `\\\" && echo ansible-tmp-1563095866.35-35005751701263=\\\"` echo /.ansible/tmp/ansible-tmp-1563095866.35-35005751701263 `\\\" ), exited with result 1\", \"unreachable\": true}, {\"_ansible_ignore_errors\": null, \"_ansible_item_label\": \"apiVersion: template.openshift.io/v1\\nkind: templates\\nmetadata:\\n annotations:\\n defaults.template.kubevirt.io/disk: rootdisk\\n description: This template can be used to create a VM suitable for Red Hat Enterprise\\n Linux 7 and newer. The template assumes that a PVC is available which is providing\\n the necessary RHEL disk image.\\n iconClass: icon-rhel\\n
Hi, this error doesn't necessarily mean the ssp-operator is failing. What's the reported status (oc get pods/oc describe pod). Are the SSP subcomponent (templates, validator) deployed succesfully?
(In reply to Francesco Romani from comment #1) > Hi, this error doesn't necessarily mean the ssp-operator is failing. What's > the reported status (oc get pods/oc describe pod). Are the SSP subcomponent > (templates, validator) deployed succesfully? It seems that this error does not block anything, I was able run a VM. $ oc get pods NAME READY STATUS RESTARTS AGE cdi-apiserver-799b86cd47-4ptkq 1/1 Running 0 23h cdi-deployment-67855b764d-qvch9 1/1 Running 3 23h cdi-operator-86cfbc4f55-grplp 1/1 Running 0 23h cdi-uploadproxy-7cd5bdb789-fkkc5 1/1 Running 0 23h cluster-network-addons-operator-5b565f55c6-67x2m 1/1 Running 0 23h hyperconverged-cluster-operator-844d7c45b9-zxzjb 1/1 Running 0 23h kubevirt-node-labeller-25dzp 1/1 Running 0 23h kubevirt-node-labeller-6trc2 1/1 Running 0 23h kubevirt-node-labeller-ct7rg 1/1 Running 0 23h kubevirt-node-labeller-mqbgf 1/1 Running 0 23h kubevirt-node-labeller-sv5lg 1/1 Running 0 23h kubevirt-node-labeller-xm77f 1/1 Running 0 23h kubevirt-ssp-operator-56566664dd-bbkpb 1/1 Running 0 23h kubevirt-web-ui-operator-59b646c5f-jldjb 1/1 Running 0 23h node-maintenance-operator-6b6d5756d8-6fjzj 1/1 Running 0 23h virt-api-6fd8d476f9-29gnm 1/1 Running 0 23h virt-api-6fd8d476f9-86qx6 1/1 Running 0 23h virt-controller-76d47c6546-5skp9 1/1 Running 0 23h virt-controller-76d47c6546-qnklj 1/1 Running 0 23h virt-handler-fqmj7 1/1 Running 0 23h virt-handler-m5m2c 1/1 Running 0 23h virt-handler-nbj89 1/1 Running 0 23h virt-handler-svjfg 1/1 Running 0 23h virt-handler-ttx67 1/1 Running 0 23h virt-handler-v4f6w 1/1 Running 0 23h virt-launcher-vm-cirros-46jdz 2/2 Running 0 4m29s virt-operator-578cdf677f-r922c 1/1 Running 0 23h virt-operator-578cdf677f-t8lfv 1/1 Running 0 23h virt-template-validator-54895c469-gn64f 1/1 Running 0 23h $oc get vmi NAME AGE PHASE IP NODENAME vm-cirros 4m35s Running 10.131.0.18 worker-0
Francesco, was this fixed upstream in the ssp-operator? Just did a new build of the hco-registry and I'm wondering if this should be ON_QA.
(In reply to Ryan Hallisey from comment #3) > Francesco, was this fixed upstream in the ssp-operator? Just did a new > build of the hco-registry and I'm wondering if this should be ON_QA. Nope, not fixed, because according to initial investigation it depends on timing *and* on how ansible-operator works. Since we had no report of issues beside logs, we didn't invest any more time in investigation. We may want to postpone to 2.2.0.
Francesco, what version of SSP operator contains the fix please? I see that PR in above message is not merged yet. I have kubevirt-ssp-operator:v2.1.0-17 installed, I don't see the error like in comment #0, but there are other "scary" as you said error messages, attached
(In reply to Irina Gulina from comment #8) > Francesco, what version of SSP operator contains the fix please? I see that > PR in above message is not merged yet. > > I have kubevirt-ssp-operator:v2.1.0-17 installed, I don't see the error like > in comment #0, but there are other "scary" as you said error messages, > attached The issue is still unfixed and should be postponed at least to 2.1.1 - but I don't have the permissions to do that. AFAIK the only real issue here is warnings in the logs, we are not aware of real issues preventing the operator to work.
moving away from ON_QA based on comment #9
Moving to 2.2 in order to handle the quick turnaround for 2.1.1. Let me know if you disagree.
It's a cosmetic issue according to #9 thus moving it out.
we believe this is fixed already in 2.2.0 need to verify
Please add fixed in version
>> oc logs kubevirt-ssp-operator-7444555b99-sd9vn -n openshift-cnv | grep -i 'permissions|failure|fail|error|authenticate' >> There is no comment#0 error in SSP pod logs. SSP versions rh-osbs/container-native-virtualization-kubevirt-ssp-operator@sha256:54df8071932123fbe9890d460fb8611ce9fc22e3f6db4ded23841eaf09037528 HCO version: rh-osbs/container-native-virtualization-hyperconverged-cluster-operator@sha256:b449706d20bd97af7915804f493b32d6099c302ffe7a524a2d6cfab8a2658cf1 Created At 2020-02-21 09:23:25 OCP 4.4 + CNV 2.3
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:2011