Merge contents in the container with those in bind mounted directories on host

[Heng-Zhou]

Merge contents in the container with those in bind mounted directories on host

[dtrudg]

In order to merge external directories with the contents of a container, SingularityCE already supports overlays.

To get the behaviour you want, merging the host $HOME with the container $HOME, you could try to:

• Disable the default bind mount of $HOME into the container (--no-mount home,cwd)
• Instead, add an overlay of the host $HOME onto the container $HOME (see https://docs.sylabs.io/guides/4.0/user-guide/persistent_overlays.html#directory-overlay)

However...

Some software read settings from $HOME (which is a convention) and users wish to create a container with some settings already saved in $HOME directory.

... this won't generally work well, even with the above, because with Singularity, your home directory path in the container is the same as on the host, by default. Your settings files in the container will only be at the right place when the $HOME directory on the host is the same as in the container. If another user uses the container, or you run it on a system with a different $HOME directory path, it will not work as expected.

It's important to note that Singularity was written specifically to support different workflows to Docker. It's expected with Singularity that license files etc. will be kept in the host $HOME and automatically bind mounted in, to avoid containers become specific to one user, or leaking a license to the public etc. when a container is shared.

As mentioned elsewhere, I strongly advise writing your Dockerfiles that will be used with Singularity so that no software or settings in the container are installed in $HOME in the container.

This is documented as a best practice: https://docs.sylabs.io/guides/4.0/user-guide/singularity_and_docker.html#best-practices-for-docker-singularityce-compatibility

As an aside - rather than open multiple issues, it would be better to approach this in the Disccussions Q&A section, giving full details of what it is you are trying to accomplish. If any feature requests result from discussion there, then we can think about tracking them as issues.

[Heng-Zhou]

In order to merge external directories with the contents of a container, SingularityCE already supports overlays.

To get the behaviour you want, merging the host $HOME with the container $HOME, you could try to:

* Disable the default bind mount of $HOME into the container (`--no-mount home,cwd`)

* Instead, add an overlay of the host $HOME onto the container $HOME (see https://docs.sylabs.io/guides/4.0/user-guide/persistent_overlays.html#directory-overlay)

However...

Some software read settings from $HOME (which is a convention) and users wish to create a container with some settings already saved in $HOME directory.

... this won't generally work well, even with the above, because with Singularity, your home directory path in the container is the same as on the host, by default. Your settings files in the container will only be at the right place when the $HOME directory on the host is the same as in the container. If another user uses the container, or you run it on a system with a different $HOME directory path, it will not work as expected.

It's important to note that Singularity was written specifically to support different workflows to Docker. It's expected with Singularity that license files etc. will be kept in the host $HOME and automatically bind mounted in, to avoid containers become specific to one user, or leaking license to the public etc.

As mentioned elsewhere, I strongly advise writing your Dockerfiles that will be used with Singularity so that no software or settings in the container are installed in $HOME in the container.

This is documented as a best practice: https://docs.sylabs.io/guides/4.0/user-guide/persistent_overlays.html#directory-overlay

As an aside - rather than open multiple issues, it would be better to approach this in the Disccussions Q&A section, giving full details of what it is you are trying to accomplish. If any feature requests result from discussion there, then we can think about tracking them as issues.

I have no idea about Docker. I did not mean to ask Singularity to work the same way as Docker. I just want to ask Singularity to work the way a normal user would expect.

Why not let other people to listen to me, instead of closing my ticket in such a hurry? That you think unreasonable does not mean it is really unreasonable.

[dtrudg]

Why not let other people to listen to me, instead of closing my ticket in such a hurry? That you think unreasonable does not mean it is really unreasonable.

Sorry that you feel your thoughts have not been heard.

When the issue is really a usage question, or relates to best practices building a container, it's better to keep it in the Discussions Q&A section: https://github.com/sylabs/singularity/discussions

We are happy to keep discussions there open for a long time, so that anyone else can give input. We use the issues section to plan work, so we try to keep it limited to bugs or features that are likely to be implemented. We are a small team, and cannot dedicate the time it takes to managing and reviewing large numbers of open feature requests on an open source project that doesn't directly cover salaries etc.

If we do not expect to implement a requested feature, we will close an issue related to it so that there is no mis-understanding that it is being considered for implementation.

I have no idea about Docker. I did not mean to ask Singularity to work the same way as Docker. I just want to ask Singularity to work the way a normal user would expect.

Apologies - most people who ask these questions are basing their understanding / expectations on how Docker works by default. I shouldn't have assumed this, and am sorry that I did.

As I mentioned in the answer above, there is already a way to do this, using Singularity's support for overlays. Also, because of Singularity's long-term default behaviour, which we cannot change, putting files in $HOME while building a container will never work well unless a user runs with a large number of non-default flags. We don't want to encourage the creation of containers which require many runtime flags to work correctly, so it's unlikely we would add another option to merge $HOME when it's already possible using overlays.

Merging $HOME brings complexity. When files are written when the container is running, people may not understand they write out to the overlay (host $HOME), or the implications of an overlay being read-only etc.

[Heng-Zhou]

Thank you for your reply. I don't mean to mess up the boundary between general discussion and bug report. When I wrote a issue ticket, I really thought it is a bug. Maybe my standard of bug is kind of too high -- basically anything in contradiction with a normal user's expectation is considered a bug in my side. But I will have your reply in mind, and try to conform to the regulation you defined. Thanks again for your replies and reference to overlay.