Miheer, Can you further explain what you are trying to accomplish?  We believe the missing security context is a bug but it is not clear to us what the intention is of trying to bind a specific ES pod to a specific cluster node.  Please explain as well as attach the DCs for the ES nodes and any PV/PVC definitions.

We have deployed our logging stack based in docs here: https://docs.openshift.com/container-platform/3.5/install_config/aggregate_logging.html#aggregated-elasticsearch

As you can see, the instructions showed using local storage for Elasticsearch and each ES instance has to be bound to specify ES node with nodeSelector.
<<<
apiVersion: v1
kind: DeploymentConfig
spec:
  template:
    spec:
      nodeSelector:
        logging-es-node: "1" 
>>>

and point number 3 says: 
The Elasticsearch replicas must be located on the correct nodes to use the local storage, and should not move around even if those nodes are taken down for a period of time. 

What we are trying to achieve is: how can we prevent the automated logging upgrade ansible playbook to not overwrite the above configuration?

No PV and PVC been used in this case.

Resolved in PR openshift-ansible/pull/5143

Has this been fixed in atomic-openshift-ansible yet?  Can we move this to ON_QA?

The PR wasn't merged to latest v3.5 branch.  It should merged to v3.3 and attached to an installer errata.

Verified and pass using openshift-ansible-3.5.125-

$ cat v34_securitygroup
        securityContext:
          supplementalGroups:
--
        securityContext:
          supplementalGroups:
--
        securityContext:
          supplementalGroups:

$ cat v34_nodeSelector
        nodeSelector:
          logging-node: "1"
--
        nodeSelector:
          logging-node: "2"
--
        nodeSelector:
          logging-node: "3"



$ cat v35_securitygroup
        securityContext:
          supplementalGroups:
--
        securityContext:
          supplementalGroups:
--
        securityContext:
          supplementalGroups:

 cat v35_nodeSelector
        nodeSelector:
          logging-node: "1"
        restartPolicy: Always
        securityContext:
--
        nodeSelector:
          logging-node: "2"
        restartPolicy: Always
        securityContext:
--
        nodeSelector:
          logging-node: "3"
        restartPolicy: Always
        securityContext:

I miss one securityContext in comment 10. There are two securityContext in DC. 
The first is created by ansible. 
The second  is created by 'oc patch' command following the document [1] 
The second one is still overwrote when using the openshift-ansible-3.5.125 with the fix PR.

@Jeff, could you confirm if we need to persist the second securityContext.?


[1]
https://docs.openshift.com/container-platform/3.5/install_config/aggregate_logging.html-> Persistent Elasticsearch Storage -> 2. Each Elasticsearch replica definition must be patched to claim that privilege, for example:
$ for dc in $(oc get deploymentconfig --selector logging-infra=elasticsearch -o name); do
    oc scale $dc --replicas=0
    oc patch $dc \
       -p '{"spec":{"template":{"spec":{"containers":[{"name":"elasticsearch","securityContext":{"privileged": true}}]}}}}'
  done

@Anping,

I think if this is the only way for the logging stack to continue to work after they applied this patch that it is reasonable to expect us to need to preserver the 'privileged': true

Opened https://bugzilla.redhat.com/show_bug.cgi?id=1478771 to address c#11

@Jeff, I think the opened bug is https://bugzilla.redhat.com/show_bug.cgi?id=1496271.

we only preserved the nodeSelector in this bug fix.

The nodeSelector is preserved. so move to verified. the securityContext issue will be fixed in  Bug1496271

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-2017:2900