-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos: make virtualisation.docker.storageDriver optional #10100
Conversation
Fixes #9801 |
Commit 9bfe92e is correct; tests do fail without an explicit --storage-driver= option. Hm... |
I'm no docker expert, but it might be the default backend that is broken, not that --storage-driver= needs to be set. From
Looks like devicemapper (dev dm-1) has some issues... |
Yes, same error with
|
af1d1b2
to
c6f91d2
Compare
Would be great to "fix" this also for |
"devicemapper" seems to work fine on my machine. Is it just NixOS VM tests that crashes? I see a couple of ways forward:
Thoughts? |
|
Honestly I think that storagedriver being mandatory is a good thing. What if docker decides to change default value? Rather we can pick a default value in the nixos option, and I don't even think that's a good idea. |
@lethalman: That last sentence confused me. What do you suggest? |
@geerds: Yes, I think "devicemapper" is the default. But it breaks in VM tests. Ideally, we'd find the real cause for the VM test breakage and fix that, instead of changing the defaults. |
@lethalman: If docker changes its default backend (and NixOS does not have a default one), we'd have to rebuild all containers, apparently. Is that a big deal? (I don't think so.) But if changing backend is a big deal, we (NixOS) should definitely not do that. Meaning, we use "devicemapper" or null as default for storageDriver. Or remove that option completely and let users pass --storage-driver=x in extraOptions. (I think the last option is what I'm leaning towards at the moment.) |
@bjornfor it is a problem, if you have a database or something like that on a container filesystem. Or we just require the user the specify the storage driver, as is now, perhaps with an assertion which is more user-friendly. |
I agree with @lethalman that forcing you to specify a storage driver is a good thing. Mainly because it is an important decision that will depend on other factors, like what file system you are using. |
Ah, right. Forgot about data :-) I tried adding an assert, but it failed: bjornfor@ff74e35 Maybe you know how to fix it? |
c6f91d2
to
ffd2375
Compare
Commit 9bfe92e ("docker: Minor improvements, fix failing test") added this option and made it mandatory. But docker itself has a default value, so I don't think NixOS should to force users to make up their mind about what storage driver to use, when docker can choose one itself. The problem is that docker's default driver is 'devicemapper' and it fails in the NixOS VM tests. Hence, the docker tests are untouched (still run with 'overlay'), but a FIXME note is added.
ffd2375
to
4159413
Compare
@ragnard, @lethalman: Do you have strong feelings about mandatory storageDriver? I think that since docker doesn't have mandatory --storage-driver=x option, neither should NixOS. And my attempt at adding an assert failed (see bjornfor@ff74e35). So the current situation is bad and this PR will improve it, I'd like to merge. |
Don't forget that, without the assert, users get an ugly traceback when they switch on services.docker.enable = true. |
My opinion is that it must be mandatory, just like when you create ordinary filesystems. I wonder what happens if docker changes default value... |
@lethalman: Ok. Can you please have a look at how to fix that assert then? I made an attempt at bjornfor@ff74e35, but it doesn't work. |
@lethalman: How about we make the default "devicemapper", which is the current docker default? Then it is explicit and won't change even if docker changes its default. |
@bjornfor yeah let's go for it |
@bjornfor @lethalman I will investigate after lunch. If I understand correctly the problem you are trying to work-around is the fact that mandatory options do not output any detailed information, right? You don't need a nullOr type to add this assertion, the module system can let you query if an option is defined or not, by adding the |
@nbp the problem is that assertion will not be triggered. Anyway we'll probably go for a default value at nix level. But would be good to know why the assertion doesn't work as expected... |
I made a new PR (because the meaning of the PR is changed): #10226 |
Commit 9bfe92e ("docker: Minor improvements, fix failing test") added the services.docker.storageDriver option, made it mandatory but didn't give it a default value. This results in an ugly traceback when users enable docker, if they don't pay enough attention to also set the storageDriver option. (An attempt was made to add an assertion, but it didn't work, possibly because of how "mkMerge" works.) The arguments against a default value were that the optimal value depends on the filesystem on the host. This is, AFAICT, only in part true. (It seems some backends are filesystem agnostic.) Also, docker itself uses a default storage driver, "devicemapper", when no --storage-driver=x options are given. Hence, we use the same value as default. Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet unknown reasons), so we still run those with the 'overlay' driver. Closes #10100 and #10217. (cherry picked from commit 5f17aeb)
@lethalman what does |
I cannot reproduce this issue locally, unless the asserting mechanism is no longer working, the option is well evaluated:
with the following test file:
Did you forgot to set the NIX_PATH to use the modified version? |
@lethalman @bjornfor Do you have a minimal config which reproduce the lack of error message reports? The assertions are executed when producing the toplevel of the system, which should happen in all cases. Maybe you are using a different target for building which does not involve evaluating these assertions. |
Uhm maybe, I was sure I tested of course with that change. Will try again... |
Commit 9bfe92e ("docker: Minor improvements, fix failing test") added the services.docker.storageDriver option, made it mandatory but didn't give it a default value. This results in an ugly traceback when users enable docker, if they don't pay enough attention to also set the storageDriver option. (An attempt was made to add an assertion, but it didn't work, possibly because of how "mkMerge" works.) The arguments against a default value were that the optimal value depends on the filesystem on the host. This is, AFAICT, only in part true. (It seems some backends are filesystem agnostic.) Also, docker itself uses a default storage driver, "devicemapper", when no --storage-driver=x options are given. Hence, we use the same value as default. Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet unknown reasons), so we still run those with the 'overlay' driver. Closes NixOS#10100 and NixOS#10217. (cherry picked from commit 5f17aeb)
Commit 9bfe92e ("docker: Minor improvements, fix failing test") added
this option and made it mandatory. But docker itself has a default
value, so I don't think NixOS should to force users to make up their
mind about what storage driver to use, when docker can choose one
itself.