Description of problem: dc.spec.template.spec.initContainers cannot be updated with oc replace, oc edit or oc apply. Also there is no way to completely remove them, so the only workaround is to delete the deploymentconfig (replication controller or whatever). This issue was fixed here: https://github.com/kubernetes/kubernetes/issues/47264 Version-Release number of selected component (if applicable): v3.7.119 How reproducible: Always Steps to Reproduce: 1. Create a dc with an initContainer 2. Try to modify the initContainer image or to delete the initContainer. Actual results: Cannot be modified Expected results: Can be modified Additional info: There is an impactbecause this means the rolling release capcity is lost
What is the output of the oc replace/edit/apply commands?
Possible workarounds: 1- use /apis/apps.openshift.io/v1/namespaces/<ns>/deploymentconfigs/<dc> instead of /oapi/v1/namespaces/<ns>/deploymentconfigs/<dc> 2- Use a deploymentconfig. Because the deploymentConfig updates the image on /apis/apps.openshift.io/v1/namespaces/<ns>/deploymentconfigs/<dc> it seems to be updating the image sucessfully. Proof of the workaround: 1- Create a dc with an init container $ oc get dc hello-openshift -o yaml | grep initContainers: -A5 initContainers: - command: - sh - -c - sleep 50 image: busybox:1.28 $ curl \ --cacert /etc/origin/master/ca-bundle.crt \ --key /etc/origin/master/openshift-master.key \ --cert /etc/origin/master/openshift-master.crt \ -H 'Content-Type: application/strategic-merge-patch+json' \ -X PATCH \ --data "$(oc get dc hello-openshift -o json | sed 's/busybox:1.28/busybox/')" https://<server>//apis/apps.openshift.io/v1/namespaces/<ns>/deploymentconfigs/<dc> [...] $ oc get dc hello-openshift -o yaml | grep initContainers: -A5 initContainers: - command: - sh - -c - sleep 50 image: busybox
This was apparently fixed in the next oc release, is there a chance customer can update to a newer version?
It's not on the table, however there is a suitable workaround.
(In reply to Juan Luis de Sousa-Valadas from comment #5) > It's not on the table, however there is a suitable workaround. Based on that, can we then close this issue?
Closing per previous comment.