Fix solr security context

[BWibo]

We need to revert 313c09c in #24, as it breaks deployment of the chart (solr) due to file permission issues.
@eidottermihi @klml Is it possible to simply overwrite the defaults at deploytime? Most people don't use OpenShift and I want to keep the default set to values that work for most people. If it's just a config change for you, that would not hurt too much, right?

# -- [k8s: Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
podSecurityContext:
  runAsUser: 8983
  runAsGroup: 8983
  fsGroup: 8983

Have you tried:

# -- [k8s: Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
podSecurityContext:
  runAsUser: 0
  runAsGroup: 0
  fsGroup: 0

With latest helm version, even this might work now:

# -- [k8s: Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
podSecurityContext: {}

[klml]

@gislab-augsburg could you try using

podSecurityContext:
  runAsUser: null
  runAsGroup: null
  fsGroup: null

[BWibo]

@klml @gislab-augsburg In OpenShift everything is owned by root, right?
If yes, this should probably work too:

# -- [k8s: Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
podSecurityContext:
  runAsUser: 0
  runAsGroup: 0
  fsGroup: 0

[klml]

@BWibo

In OpenShift everything is owned by root, right?

No, the exact opposite. Openshift assigns arbitrary UIDs higher than 1000

[BWibo]

OK, thx. Then my proposal of before is probably no option.

• Does the value have to be null to allow setting OpenShift this to an arbitrary UID?
• Can we assign a UUID in the valid range to get it running?

This could be another option worth testing:

# -- [k8s: Security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
podSecurityContext:
  runAsUser: ""
  runAsGroup: ""
  fsGroup: ""

The problem is that the solr volume for persisting data is not owned by the correct user (which is set in the solr base image to UID 8983).

Executing /opt/docker-solr/scripts/solr-precreate ckan /opt/solr/server/solr/configsets/ckan
Copying solr.xml 
cp: cannot create regular file '/var/solr/data/solr.xml': Permission denied                                                                    
Stream closed EOF for bruno/solr-0 (solr)

So we could resolve this by implementing the same mechanism as in #32 and use an initContainer to fix the permissions. You can then overwrite this initContainer like you do for the ckan pod.

[BWibo]

I solved it as described above. @gislab-augsburg forget about testing the securityContext. But please try out the new approach with initContainer, just like we did for ckan in #32.