Description of problem: Kubernetes resources are stored with wrong prefix, openshift.io instead of the default kubernetes.io The problem is here: https://github.com/openshift/cluster-kube-apiserver-operator/blob/7ccbe08cca0490f722f635345df7da9072db53ba/bindata/v4.1.0/kube-apiserver/defaultconfig.yaml#L111 this should never be set since we have defaulting in place for k8s in https://github.com/openshift/origin/blob/7599337aeefb8314f9b5bb832b42639d4e28ce26/pkg/cmd/openshift-kube-apiserver/configdefault/kubecontrolplane_default.go#L58 and origin in https://github.com/openshift/origin/blob/7599337aeefb8314f9b5bb832b42639d4e28ce26/pkg/cmd/openshift-kube-apiserver/configdefault/openshiftcontrolplane_default.go#L9
Fixes in: master: https://github.com/openshift/cluster-kube-apiserver-operator/pull/475 4.1: https://github.com/openshift/cluster-kube-apiserver-operator/pull/476
First check the issue in old payload env 4.1.0-0.nightly-2019-05-14-202907: Check /etc/kubernetes/static-pod-resources/configmaps/config/config.yaml, there is "storagePrefix":"openshift.io". Then check etcd resources: $ oc rsh -n openshift-etcd etcd-member-ip-10-0-140-235.ap-south-1.compute.internal sh-4.2# export ETCDCTL_API=3 ETCDCTL_CACERT=/etc/ssl/etcd/ca.crt ETCDCTL_CERT=`ls /etc/ssl/etcd/*etcd-peer*crt` ETCDCTL_KEY=`ls /etc/ssl/etcd/*etcd-peer*key` sh-4.2# etcdctl get / --endpoints 127.0.0.1:2379 --prefix --keys-only | grep "^/kubernetes.io/" # get nothing Then check the issue in latest payload 4.1.0-0.nightly-2019-05-16-001402, /etc/kubernetes/static-pod-resources/configmaps/config/config.yaml doesn't have "storagePrefix":"openshift.io", `etcdctl get / --endpoints 127.0.0.1:2379 --prefix --keys-only` shows both /kubernetes.io/ resources and /openshift.io/ resources correctly.
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-2019:0758