I don't know. But should be within a minute or so. Do note that this refresh ability does depend on it being enabled in the cluster master configuration. It should be, although have seen where cluster was upgraded from 3.5 to 3.6, the setting somehow got lost and had to be fixed after the fact when issue was found that refresh wasn't occuring.
Graham > On 13 Dec 2017, at 9:33 pm, Joel Pearson <[email protected]> > wrote: > > 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 > > <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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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] <mailto:[email protected]> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >> <http://lists.openshift.redhat.com/openshiftmm/listinfo/users> > > _______________________________________________ > 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
