If you copy it rather than symlink, you will loose the ability that an update to the configmap will be reflected automatically inside of the container after a short period. If the file was something that was rescanned by the application, this allows changes to be pushed into a container without needing to do a restart. If you only read the file once on start up, then copying would be fine.
Graham > On 13 Dec 2017, at 8:26 pm, Tim Dudgeon <[email protected]> wrote: > > Graham, > > Thanks for your help on this. > I had managed to work around the problem in a way similar to how you > described (but copying not symlinking). Not nice, but it works! > > On 12/12/17 21:10, Graham Dumpleton wrote: >> A belated update on this. >> >> The problem with using subPath is due to a SELinux issue in the kernel. >> >> There is an issue about it at: >> >> https://github.com/openshift/origin/issues/16951 >> <https://github.com/openshift/origin/issues/16951> >> >> Whether you see it will depend on how SELinux is setup I guess. >> >> The only work around would be to mount it as a directory '..data' in the >> target directory, and then you create a symlink from startup run script in >> your source code to symlink the file in the '..data' directory into the >> parent. Know of no other solution at this point. >> >> Graham >> >>> On 9 Dec 2017, at 8:36 pm, Tim Dudgeon <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> If you mount onto a new directory you get the same problem. >>> It only seems to happen when specifying a subPath as follows: >>> >>> - mountPath: >>> /usr/local/tomcat/webapps/portal/META-INF/context.xml >>> name: squonk-sso-config >>> subPath: context.xml >>> readOnly: true >>> >>> If the whole configMap is mounted to a directory the contents are readable. >>> >>> And as mentioned already, if you do this in Minishift it works fine. >>> >>> >>> On 09/12/17 02:16, Graham Dumpleton wrote: >>>> The permissions is correct. It is shown as decimal, not the octal you are >>>> setting it with. >>>> >>>>>>> '%o' % 420 >>>> '644' >>>> >>>> What happens when you mount the configmap onto a directory separate from >>>> anything else? >>>> >>>> Graham >>>> >>>>> On 9 Dec 2017, at 4:02 am, Tim Dudgeon <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> More on this. >>>>> >>>>> I find when I look a the deployment yaml that the volume ends up looking >>>>> like this: >>>>> >>>>> volumes: >>>>> - configMap: >>>>> defaultMode: 420 >>>>> name: squonk-sso-config >>>>> name: squonk-sso-config >>>>> >>>>> This is despite `oc explain pod.spec.volumes.configMap` stating that the >>>>> default for defaultMode is 0644. >>>>> >>>>> Even when I specify defaultMode: 0644 in the template it ends up being >>>>> 420. >>>>> >>>>> Any idea what's going on? >>>>> >>>>> >>>>> On 08/12/17 16:44, Tim Dudgeon wrote: >>>>>> Hi All, >>>>>> >>>>>> I'm having a problem mounting a file from a ConfigMap when running on an >>>>>> Openshift origin environment, but when doing the same on Minishift it >>>>>> works fine. >>>>>> >>>>>> I'm mounting the context.xml file from the ConfigMap into the container >>>>>> like this: >>>>>> >>>>>> spec: >>>>>> containers: >>>>>> - image: ... >>>>>> ... >>>>>> volumeMounts: >>>>>> - mountPath: >>>>>> /usr/local/tomcat/webapps/portal/META-INF/context.xml >>>>>> name: my-configmap-vol >>>>>> subPath: context.xml >>>>>> readOnly: true >>>>>> volumes: >>>>>> - name: my-configmap-vol >>>>>> configMap: >>>>>> name: squonk-sso-config >>>>>> >>>>>> Within the container the file is there but has permissions problems: >>>>>> >>>>>> # ls -l >>>>>> ls: cannot access 'context.xml': Permission denied >>>>>> total 4 >>>>>> -rw-r--r--. 1 root root 104 Dec 5 12:48 MANIFEST.MF >>>>>> -?????????? ? ? ? ? ? context.xml >>>>>> >>>>>> Any idea what's the problem? >>>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> >>> >> > > _______________________________________________ > users mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
