Version: 4.4.0-0.nightly-2020-03-20-094134 During deployment I see the following message repeating continuously on the bootstrap vm when I run: 'journalctl -b -f -u bootkube.service': Mar 22 01:26:55 localhost bootkube.sh[17541]: "99_openshift-machineconfig_99-worker-ssh.yaml": unable to get REST mapping for "99_openshift-machineconfig_99-worker-ssh.yaml": no matches for kind "MachineConfig" in version "machineconfiguration.openshift.io/v1" The deployment completes successfully despite these message.
These errors are normal, the bootstrap node attempts to apply manifests continually until they succeed. This particular error is because the machine-config-operator hasn't created it's CRD's, and it goes away once it comes up.
Actually after discussing we think it might be helpful if the bootkube logs either surpressed these messages, or provided an indication to the user that these are expected until the operator is available. We get reports constantly about these messages from end users of OCP.
> Actually after discussing we think it might be helpful if the bootkube logs either surpressed these messages the bootkube service is not going to do any such suppressing, MCO should render the CRD on bootstrap host like other operators if we want to remove these messages. > or provided an indication to the user that these are expected until the operator is available. We get reports constantly about these messages from end users of OCP. that information is not available to bootkube (cluster-bootstrap) script and I don't think it should be available to it. It's job is to push manifests to cluster and that it. it doesn't need to know which operator provides these resources. Moving to MCO to decide if they want to add the CRD in early stage, if not this bug should be closed as wontfix.
(In reply to Abhinav Dahiya from comment #3) > > Actually after discussing we think it might be helpful if the bootkube logs either surpressed these messages > > the bootkube service is not going to do any such suppressing, MCO should > render the CRD on bootstrap host like other operators if we want to remove > these messages. > > > or provided an indication to the user that these are expected until the operator is available. We get reports constantly about these messages from end users of OCP. > > that information is not available to bootkube (cluster-bootstrap) script and > I don't think it should be available to it. It's job is to push manifests to > cluster and that it. it doesn't need to know which operator provides these > resources. > > Moving to MCO to decide if they want to add the CRD in early stage, if not > this bug should be closed as wontfix. which is something scheduled for either 4.5 or 4.6 so, lowering priority accordingly and moving to 4.5 as target
*** Bug 1821912 has been marked as a duplicate of this bug. ***
This certainly seems to be happening quite frequently in 4.4 though potentially as a result of other unrelated problems? See duped bug.
*** Bug 1828965 has been marked as a duplicate of this bug. ***
Thanks Antonio for including in the discussion. I'm with Stephen Benjamin on this one. If not willing to suppress messages, then if the CRD can happen earlier on so that it doesn't flood bootkube.service that be ideal. In essence, these messages make reading the messages within the cmd "journalctl -f -u bootkube.service" very difficult.
Verified on 4.5.0-0.nightly-2020-04-30-112808. There are only a few lines of this early on in the install now while the CRD is being created compared to before.
*** Bug 1848910 has been marked as a duplicate of this bug. ***
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 (OpenShift Container Platform 4.5 image release 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/RHBA-2020:2409