K
Q

Does Openshift "oc apply" overwrite the entire configuration or only the included parameters?

1/8/2020

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):

oc apply -f configmap.yml

My question is:

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?

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

-- semmelbroesel
kubernetes
openshift

Similar Questions

What is the best way to run a python process on a separate compute instance with Google Cloud Composer?
Rest end point for getting the bearer token from openshift
accessing Memcached through mcrouter from Rails in Kubenetes
Cannot reach bind dns in Kubernetes

2 Answers

1/9/2020

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.

Let's go trough it together...

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

oc apply -f configmap_lab.yaml

As we can see, we have everything included as expected:

$ 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

Now let's deploy a new yaml over this one:

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

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

oc apply -f configmap_lab_new.yaml
$ 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

As we can notice, all changes where accepted and are active.

Although if you want to do it in a more controlled way, you may want to use oc patch. Doc here.

-- mWatney
Source: StackOverflow
1/8/2020

oc apply computes and applies differences between objects:

It performs a three-way merge between:

  1. the input into the command,

  2. the current version of the object, and

  3. the most recent user specified object definition stored as an annotation in the current object.

The existing object is then updated with the result.

There's more at this link to the doc.

-- gears
Source: StackOverflow