[libvirt provider] certificate approve is not working for master and worker nodes about cluster-machine-approver HOT 13 CLOSED

from cluster-machine-approver.

I dunno about shipping the qemu guest agent in RHCOS. We're trying to avoid special agents.

from cluster-machine-approver.

@cgwalters Praveen created a PR that drops the use of dom.GetHostname(0): openshift/cluster-api-provider-libvirt#125

from cluster-machine-approver.

Possible that dom.GetHostname(0) depends on the qemu-guest-agent https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetHostname

from cluster-machine-approver.

I figured it out! dom.GetHostname(0) is not implemented for qemu-kvm backend of libvirt until version 4.8.0 and we don't have that even in Fedora 29 updates testing repos. So I'd guess most people don't have it and hence openshift/cluster-api-provider-libvirt#122 does not work for them.

from cluster-machine-approver.

I am using CentOS testing repo which have 5.0.0 version of libvirt so I think it might something to do with qemu-guest-agent, will try that also and comment.

$ rpm -qa | grep libvirt
libvirt-daemon-kvm-5.0.0-1.el7.x86_64
libvirt-daemon-driver-nwfilter-5.0.0-1.el7.x86_64
libvirt-daemon-config-nwfilter-5.0.0-1.el7.x86_64
libvirt-daemon-driver-qemu-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-logical-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-5.0.0-1.el7.x86_64
libvirt-5.0.0-1.el7.x86_64
libvirt-devel-5.0.0-1.el7.x86_64
libvirt-libs-5.0.0-1.el7.x86_64
libvirt-daemon-driver-network-5.0.0-1.el7.x86_64
libvirt-daemon-driver-nodedev-5.0.0-1.el7.x86_64
libvirt-daemon-config-network-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-core-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-gluster-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-disk-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-iscsi-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-mpath-5.0.0-1.el7.x86_64
libvirt-bash-completion-5.0.0-1.el7.x86_64
libvirt-daemon-5.0.0-1.el7.x86_64
libvirt-daemon-driver-secret-5.0.0-1.el7.x86_64
libvirt-daemon-driver-lxc-5.0.0-1.el7.x86_64
libvirt-client-5.0.0-1.el7.x86_64
libvirt-daemon-driver-interface-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-scsi-5.0.0-1.el7.x86_64
libvirt-daemon-driver-storage-rbd-5.0.0-1.el7.x86_64

from cluster-machine-approver.

So I also have qemu-guest-agent installed on that system so something else which stopping it.

$ rpm -qa | grep qemu
libvirt-daemon-driver-qemu-5.0.0-1.el7.x86_64
qemu-guest-agent-2.12.0-2.el7.x86_64
qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
qemu-img-ev-2.12.0-18.el7_6.3.1.x86_64
qemu-kvm-common-ev-2.12.0-18.el7_6.3.1.x86_64

from cluster-machine-approver.

So what we actually want to be part of status is it hostname or hostname -f ?

$ ssh [email protected] hostname
test1-rqt27-master-0

$ ssh [email protected] hostname -f
test1-rqt27-master-0.test1.openshift.testing

from cluster-machine-approver.

@abhinavdahiya Status from a AWS cluster is which means it take the internal DNS so for libvirt it should be <name>.<domain> right?

Status:
  Addresses:
    Address:     10.0.157.212
    Type:        InternalIP
    Address:     
    Type:        ExternalDNS
    Address:     ip-10-0-157-212.ap-northeast-1.compute.internal
    Type:        InternalDNS

from cluster-machine-approver.

@cgwalters, @praveenkumar,

Is there any update on the case?

Regards,
Fábio Sbano

from cluster-machine-approver.

We've been seeing a similar thing on our baremetal deployments where we have to manually approve certs. My machine-approver log has a bunch of:

I0321 18:09:39.113975       1 main.go:97] CSR csr-grgft added
I0321 18:09:39.133134       1 main.go:123] CSR csr-grgft not authorized: No target machine
I0321 18:14:32.453059       1 main.go:97] CSR csr-f66gv added
I0321 18:14:32.464451       1 main.go:123] CSR csr-f66gv not authorized: No target machine
I0321 18:18:11.088381       1 main.go:97] CSR csr-jmf46 added
I0321 18:18:11.102598       1 main.go:123] CSR csr-jmf46 not authorized: No target machine
I0321 18:22:27.112564       1 main.go:97] CSR csr-zxjkn added
I0321 18:22:27.127977       1 main.go:123] CSR csr-zxjkn not authorized: No target machine
I0321 18:27:20.454085       1 main.go:97] CSR csr-f85k9 added

What are the names that are supposed to line up between a csr and machine here?

from cluster-machine-approver.

Nevermind, I think I've sorted out the cause on ours. The symptoms are similar, but the root cause is different. We'll track it from openshift-metal3/dev-scripts#141

from cluster-machine-approver.

Please reopen if changes to this repo are required.

from cluster-machine-approver.