Oh, I didn't realise configmaps got updated without a Pod restart. How long does it take to update? I see in ( https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically) it says the kubelet sync period + ttl. What are the OpenShift defaults for that?
On Wed, Dec 13, 2017 at 8:41 PM Graham Dumpleton <gdump...@redhat.com> wrote: > 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 <tdudgeon...@gmail.com> 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 > > 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 <tdudgeon...@gmail.com> 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 <tdudgeon...@gmail.com> 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 > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > > > > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > > > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users