<p>We are currently using the following command to update configmap settings in Openshift (after which we restart the pods for the settings to take effect):</p>

<pre><code>oc apply -f configmap.yml
</code></pre>

<p>My question is:</p>

<p>Will this command delete the existing configmap and replace it with the content of this file, or does it only import the settings from the file and leaving any other settings untouched?</p>

<p>Basically, if the live configmap contains a setting <code>mytest: true</code> and the new file does not include the parameter <code>mytest</code>, does the parameter remain in the live configmap in Openshift, or does it get deleted because it is not listed in the imported file?</p>

<p>I've reproduced your case and after applying new yaml with different configmap settings, the new version is taking place. So OpenShift isn't merging configmap, it's replacing. </p>

<p>Let's go trough it together...</p>

<pre><code>kind: ConfigMap
apiVersion: v1
metadata:
  name: example-config
data: 
  mytest0: "HELLO"
  mytest1: "STACK"
  mytest2: "COMMUNITY"
  mytest3: "!!!"
</code></pre>

<p><code>oc apply -f configmap_lab.yaml</code></p>

<p>As we can see, we have everything included as expected:</p>

<pre><code>$ oc get configmap/example-config -o yaml
apiVersion: v1
data:
  mytest0: HELLO
  mytest1: STACK
  mytest2: COMMUNITY
  mytest3: '!!!'
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"mytest0":"HELLO","mytest1":"STACK","mytest2":"COMMUNITY","mytest3":"!!!"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"example-config","namespace":"myproject"}}
  creationTimestamp: 2020-01-09T10:42:11Z
  name: example-config
  namespace: myproject
  resourceVersion: "7987774"
  selfLink: /api/v1/namespaces/myproject/configmaps/example-config
  uid: b148dbef-32cc-11ea-9339-525400d653ae
</code></pre>

<p>Now let's deploy a new yaml over this one: </p>

<pre><code>kind: ConfigMap
apiVersion: v1
metadata:
  name: example-config
data: 
  mytest0: "THANKS"
  mytest1: "STACK"
  newmytest0: "COMMUNITY"
  newmytest1: "!!!"
</code></pre>

<p>Here we are changing the value, removing 2 and adding 2 parameters. Let's check how OC will treat that: </p>

<pre><code>oc apply -f configmap_lab_new.yaml
</code></pre>

<pre><code>$ oc get configmap/example-config -o yaml
apiVersion: v1
data:
  mytest0: THANKS
  mytest1: STACK
  newmytest0: COMMUNITY
  newmytest1: '!!!'
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"mytest0":"THANKS","mytest1":"STACK","newmytest0":"COMMUNITY","newmytest1":"!!!"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"example-config","namespace":"myproject"}}
  creationTimestamp: 2020-01-09T10:42:11Z
  name: example-config
  namespace: myproject
  resourceVersion: "7988585"
  selfLink: /api/v1/namespaces/myproject/configmaps/example-config
  uid: b148dbef-32cc-11ea-9339-525400d653ae
</code></pre>

<p>As we can notice, all changes where accepted and are active.</p>

<p>Although if you want to do it in a more controlled way, you may want to use <code>oc patch</code>. <a href="https://labs.consol.de/development/2019/04/08/oc-patch-unleashed.html" rel="nofollow noreferrer">Doc here</a>.</p>
