feat: add uid check for chown in initContainer

[d7oc]

If the initContainer is started in an environment which is rootless (e.g. OpenShift) the chown command will fail. This PR adds a check for the user id before executing chown to avoid this.

[wkloucek]

I would prefer a solution like this: https://github.com/owncloud/ocis-charts/blob/08943e7b50b39a055bb86b90c03c39c03d51e55f/charts/ocis/values.yaml#L427-L430

[d7oc]

Indeed this was also the second solution I had in mind, just with the difference to use the skipChown we already have for the "normal" container. I'm agnostic here which solution we should take. The upside of the current patch would be that the user doesn't have to care, it will just work. The downside is of course missing flexibility.

[wkloucek]

Indeed this was also the second solution I had in mind, just with the difference to use the skipChown we already have for the "normal" container. I'm agnostic here which solution we should take. The upside of the current patch would be that the user doesn't have to care, it will just work. The downside is of course missing flexibility.

I wonder how you can force the initcontainer to run as root!? oCIS is doing it like this https://github.com/owncloud/ocis-charts/blob/08943e7b50b39a055bb86b90c03c39c03d51e55f/charts/ocis/templates/idm/deployment.yaml#L28-L38

[d7oc]

I wonder how you can force the initcontainer to run as root!? oCIS is doing it like this https://github.com/owncloud/ocis-charts/blob/08943e7b50b39a055bb86b90c03c39c03d51e55f/charts/ocis/templates/idm/deployment.yaml#L28-L38

This happens automatically on k3d and Minikube. Only OpenShift behaves differently and just executes the initContainer with a random UID.

So I guess the securityContext defaults differ

[xoxys]

I would prefer the approach from the ocis chart. @d7oc can you adapt it? I'm ok to reuse the existing skipChown property.

[d7oc]

I would prefer the approach from the ocis chart. @d7oc can you adapt it? I'm ok to reuse the existing skipChown property.

Changed.

[xoxys]

I was more talking about the two dedicated init containers as shown in the ocis example https://github.com/owncloud/ocis-charts/blob/master/charts/ocis/templates/idm/deployment.yaml#L28-L50

[d7oc]

Ah. I'm wondering how this works reliably. The execution order of the initContainers isn't determined AFAIK, so if the chown initContainer is executed before the mkdir initContainer this fails. So if I'm correct this would be an error-prone approach.

[xoxys]

Then the kubelet runs the Pod's init containers in the order they appear in the Pod's spec.

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

[d7oc]

Then the kubelet runs the Pod's init containers in the order they appear in the Pod's spec.

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

👍 Good to know.

Will change it.

Shouldn't the order in ocis-chart be changed in this case?

[d7oc]

Adapted

[d7oc]

But one thing just came to my mind, what happens if the first initContainer fails? Will the second not be executed as well?

Found the answer already so all is fine:

Each init container must exit successfully before the next container starts.