You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And create files which are intended to be temporary, interleved with existing files
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: