Add testutil daemon.WithResolvConf#49132
Conversation
| d := daemon.New(t, | ||
| daemon.WithResolvConf(network.WriteTempResolvConf(t, "127.0.0.1")), | ||
| daemon.WithExperimental(), | ||
| ) |
There was a problem hiding this comment.
Heh, this now makes it really tempting to combine those (not sure if we should), as it looks like WriteTempResolvConf is always used in combination with daemon.WithResolvConf
daemon.WithResolver(t, "127.0.0.1")There is some special handling in that utility for permissions;
moby/integration/internal/network/dns.go
Lines 20 to 24 in f95e4b3
I wonder if (as we're passing the Daemon struct to these options) if putting it somewhere inside the daemon's storage location would work for that; in that case, we'd keep all things related to that daemon instance together;
moby/testutil/daemon/daemon.go
Lines 200 to 204 in f95e4b3
moby/testutil/daemon/daemon.go
Lines 106 to 122 in f95e4b3
There was a problem hiding this comment.
Heh, this now makes it really tempting to combine those (not sure if we should), as it looks like WriteTempResolvConf is always used in combination with daemon.WithResolvConf
That'd take away the possibility of giving the daemon a more complicated resolv.conf (or a deliberately broken one).
I thought about having StartDaftDNS write its own resolv.conf, returning the filename. Then, in four of the five cases, it'd be ... daemon.WithResolvConf(network.StartDaftDNS(t, "127.0.0.1")). (In the other case, no dummy resolver gets started, the test just needs its own resolv.conf.)
But, same thing there really - it'd limit the resolv.conf, without buying much.
I wonder if (as we're passing the Daemon struct to these options) if putting it somewhere inside the daemon's storage location would work for that; in that case, we'd keep all things related to that daemon instance together;
I suppose WithResolvConf could take a []byte to write to a resolv.conf in the daemon's Folder, instead of the location of a file (so the file doesn't need to be created before the NewDaemon has created Folder). I'll try that...
There was a problem hiding this comment.
I suppose WithResolvConf could take a []byte to write to a resolv.conf in the daemon's Folder, instead of the location of a file (so the file doesn't need to be created before the NewDaemon has created Folder). I'll try that...
Oh, that might work yes!
And, yes, I was also considering "would we need more complex ones?" so yeah, I can agree.
It's mostly brainstorming a bit here, knowing that this is not a critical/urgent PR, so just looking what shape it could take to make it clean and flexible enough 😄 ❤️
There was a problem hiding this comment.
I've had a go at that ... I think it's better.
|
Unrelated Windows test failures ... |
thaJeztah
left a comment
There was a problem hiding this comment.
LGTM - left one more suggestion in case you think it makes sense (but not a blocker)
|
|
||
| tmpFileName := net.WriteTempResolvConf(t, "127.0.0.1") | ||
| d := daemon.New(t, daemon.WithEnvVars("DOCKER_TEST_RESOLV_CONF_PATH="+tmpFileName)) | ||
| d := daemon.New(t, daemon.WithResolvConf(net.GenResolvConf(t, "127.0.0.1"))) |
There was a problem hiding this comment.
Heh, very unrelated, but we should probably avoid using net as alias, as it would be clashing with Go's net package;
net "github.com/docker/docker/integration/internal/network"| func WithResolvConf(content []byte) Option { | ||
| return func(d *Daemon) { | ||
| d.resolvConfContent = content |
There was a problem hiding this comment.
Not a blocker; wondering if string as arguments (and converting to []byte internally) would make these utilities easier to use. Or at least, I often find myself creating a string, and then having to convert it to []byte, because strings tend to be easier to produce 😅
Signed-off-by: Rob Murray <[email protected]>
- What I did
Add
daemon.WithResolvConfto tidy up tests that were setting env varDOCKER_TEST_RESOLV_CONF_PATH.- How I did it
- How to verify it
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)