Bug 1825944

Summary:	cloud.conf cloudconfig is missing in openshift-managed-config/kube-cloud-config configmap
Product:	OpenShift Container Platform	Reporter:	Sinny Kumari <skumari>
Component:	Installer	Assignee:	Abhinav Dahiya <adahiya>
Installer sub component:	openshift-installer	QA Contact:	Yang Yang <yanyang>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	medium
Priority:	medium	CC:	cglombek
Version:	4.5
Target Milestone:	---
Target Release:	4.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-13 17:29:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sinny Kumari 2020-04-20 14:42:30 UTC

Description of problem:
With recent changes in 4.5 (https://github.com/openshift/api/pull/621 ) OpenShift api, all clients are supposed to read cloud config from cloud.conf present in openshift-managed-config/kube-cloud-config configmap. MCO is doing this change in PR https://github.com/openshift/machine-config-operator/pull/1658 . From failing e2-gcp-upgrade job (https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_machine-config-operator/1658/pull-ci-openshift-machine-config-operator-master-e2e-gcp-upgrade/1849/artifacts/e2e-gcp-upgrade/pods/openshift-machine-config-operator_machine-config-operator-8ccc6775-vvszh_machine-config-operator.log), it appears that cloud.conf key is not present in kube-cloud-config.

Expected results: MCO e2-gcp-op/e2-gcp-upgrade test shouldn't fail with error ` cloud.conf not found in openshift-config-managed/kube-cloud-config`

Comment 4 Yang Yang 2020-04-23 07:22:07 UTC

Reproduce it as below:
# oc get cm kube-cloud-config -n openshift-config-managed -o yaml
apiVersion: v1
data:
  config: |+   <--- The key does not set to cloud.conf
    [global]
    project-id      = openshift-qe
    regional        = true
    multizone       = true
    node-tags       = yanyan-8m6br-master
    node-tags       = yanyan-8m6br-worker
    node-instance-prefix = yanyan-8m6br
    external-instance-groups-prefix = yanyan-8m6br
    subnetwork-name = yanyan-8m6br-worker-subnet

kind: ConfigMap
metadata:
  creationTimestamp: "2020-04-23T06:24:27Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:config: {} 
    manager: cluster-config-operator
    operation: Update
    time: "2020-04-23T06:24:27Z"
  name: kube-cloud-config
  namespace: openshift-config-managed
  resourceVersion: "16145"
  selfLink: /api/v1/namespaces/openshift-config-managed/configmaps/kube-cloud-config
  uid: 3f282807-7ad1-4ece-a8f0-1cd74c737589


Verify with 4.5.0-0.nightly-2020-04-23-011740 as below:

# oc get cm kube-cloud-config -n openshift-config-managed -o yaml
apiVersion: v1
data:
  cloud.conf: |+  <--- The key is set to cloud.conf
    [global]
    project-id      = openshift-qe
    regional        = true
    multizone       = true
    node-tags       = yanyan-gbk6k-master
    node-tags       = yanyan-gbk6k-worker
    node-instance-prefix = yanyan-gbk6k
    external-instance-groups-prefix = yanyan-gbk6k
    subnetwork-name = yanyan-gbk6k-worker-subnet

kind: ConfigMap
metadata:
  creationTimestamp: "2020-04-23T04:11:51Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:cloud.conf: {}  <--- It is also aligned with key cloud.conf
    manager: cluster-config-operator
    operation: Update
    time: "2020-04-23T04:11:51Z"
  name: kube-cloud-config
  namespace: openshift-config-managed
  resourceVersion: "15264"
  selfLink: /api/v1/namespaces/openshift-config-managed/configmaps/kube-cloud-config
  uid: ae3d6981-cc87-4087-8817-e307276c20e8

The config key is updated to cloud.conf hence moving it to verified state.

Comment 5 errata-xmlrpc 2020-07-13 17:29:07 UTC

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/RHBA-2020:2409