"daemon.json wasn't where I expected to find it" is an unreliable basis to prevent building

[TBBle]

Output of the ue4-docker info command:

ue4-docker version:         0.0.98 (latest available version is 0.0.98)
Operating system:           Windows Server 2019 Standard (Build 17763.2928)
Docker daemon version:      20.10.16.1
NVIDIA Docker supported:    No
Maximum image size:         20GB
Available disk space:       3.62 TiB
Total system memory:        63.89 GiB physical, 73.39 GiB virtual
CPU:                        20 physical, 40 logical (Intel64 Family 6 Model 79 Stepping 1, GenuineIntel)

Additional details:

• Are you accessing the network through a proxy server? No

For reference, my D:\dockerdata\config\daemon.json:

{
  "data-root": "D:\\dockerdata",
  "exec-root": "D:\\dockerdata\\exec-root",
  "storage-opts": [
    "size=2000GB"
  ]
}

Yes, for reasons, our Docker data lives entirely on the D:\ drive. So when trying to do builds, we fail with the following:

[ue4-docker build] SETUP REQUIRED:
[ue4-docker build] The max image size for Windows containers must be set to at least 400.0GB.
[ue4-docker build] See the Microsoft documentation for configuration instructions:
[ue4-docker build] https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-storage#storage-limits
[ue4-docker build] Under Windows Server, the command `ue4-docker setup` can be used to automatically configure the system.

which is incorrect since we do have 2TB in our storage-opts.

This check is fraught as-is, because as well as relocating the daemon.json (which per #150 (comment) may happen simply by registering the service with a different data-root) and in my case, involved an edit to HKLM\SYSTEM\CurrentControlSet\Services\stevedor, you can also add --storage-opts to the dockerd command line.

I'm opening this issue to canvas opinions on possible resolutions. Locally, I've just stuck False and into that condition in build.py in the venv, but the next upgrade of ue4-docker on that machine will overwrite that.

Options that come to mind, in roughly-increasing order of effort (for the project):

• My use-case is invalid: I should either keep daemon.json in its default location, or put a symlink from C:\ProgramData\Docker to D:\dockerdata so ue4-docker isn't confused.
• This could be a warning, like fff76b6 for the 20GB issue. I had thought it was, until a colleague hit this failure.
• Make it a warning, and add a diagnostic to measure the effective value with dir inside a container.
• Add a "Trust me, it's big enough" flag to ignore this. Perhaps a better-named flag than --its-big-enough though.
• Support a way to point at the read config file from another location, perhaps check docker info's data-root/config/daemon.json as well, and also even a command-line flag or config setting? This doesn't help people who've set storage-opts on the command-line.
• Instead of trying to parse things, run an image we know we'll pull anyway for the build, and see what dir says inside that. (This seems slow... Perhaps cache it? Although presumably in this case, we're going to spend a lot of time building anyway)

I do note in ue4-docker info we've correctly identified the data-root drive for "Available disk space".

[slonopotamus]

My use-case is invalid: I should either keep daemon.json in its default location, or put a symlink from C:\ProgramData\Docker to D:\dockerdata so ue4-docker isn't confused.

I believe it should be OK to have dockerd even on a different machine (okay, this won't work currently because of credentials helper, but anyway).

Make it a warning, and add a diagnostic to measure the effective value with dir inside a container.

I'm leaning towards this. So, we're trying to say "hey, user, if ue4-docker diagnostics all passes for you, then your env is very likely to be good".

Support a way to point at the read config file from another location, perhaps check docker info's data-root/config/daemon.json as well, and also even a command-line flag or config setting?

That's too much overcomplicated.

[TBBle]

We actually don't check this in ue4-docker diagnostitcs all (which I had already run to verify our setup). We check that it works on the command-line for docker run (a specific bug in the Windows 1903 and 1909 releases), but we don't check the currently-configured value.

[slonopotamus]

a specific bug in the Windows 1903 and 1909 releases

... which we should just drop already :D

[TBBle]

Yeah, I was thinking that today when I was looking at that diagnostic. And I was looking at it because its current name suggested it might be doing a space-available check that I could recycle and replace the config-parsing.