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

Reply via email to