DiamondLightSource / python-copier-template

Replacing Diamond Light Source's python3-pip-skeleton using Copier
Apache License 2.0
4 stars 2 forks source link

umask of containers created from python3 Dockerfile does not match Diamond default #164

Open DiamondJoseph opened 1 month ago

DiamondJoseph commented 1 month ago

For the case where:

The current umask means those temporary files cannot be deleted by the user that created the directory that stores those files. E.g. pycache files made during an editable install of a library loaded from filesystem for blueapi, checked out by a member of dls_dasc

For blueapi (where we meet these requirements) we are now setting the umask: is anyone else going to meet those requirements and if so should this be configurable as part of the template, perhaps propagating into the Dockerfile?

coretl commented 1 month ago

@gilesknap thoughts?

gilesknap commented 1 month ago

I think it is reasonable for us to add umask into python copier template's Dockerfile. We should do so with an environment variable so that can be set up by helm charts or podman cmdline args. If the variable is not set then we would use the base image's default umask as we currently do.

For epics-containers iocs this may also be necessary - they can only write to /dls/ixx/data as ixxdetector - I don't know if this requires group membership access setting on folders? But even if it does not we should still add this feature because other facilities might have a specific umask requirement.

So in summary I agree that we should adopt this as a standard and do it via runtime configuration - I suggest an environment variable.