fix: panic if services DNS is disabled

[vbehar]

if _EXPERIMENTAL_DAGGER_SERVICES_DNS is disabled, dagger-engine crashes when starting, because the network config is nil

let's ensure that we don't fail if the network config is nil

[vito]

Makes sense, thanks!

Can I ask why you had to disable services DNS? I'm planning to remove this feature flag in the future as we haven't heard of any issues with it for a while.

[vbehar]

Can I ask why you had to disable services DNS? I'm planning to remove this feature flag in the future as we haven't heard of any issues with it for a while.

Yes sure, it's because we're using dagger to create a kube cluster on the same docker instance (already used by dagger-engine), using kind. and then we run our end-to-end tests against this cluster from dagger.

we're deploying the kube cluster directly on the docker instance because we want to easily access it from outside of the dagger context, and also keep it running after the dagger session has been closed. so basically we want a long-lived service that has its own lifecycle, independent of the dagger session.

and back to disabling the services DNS, I've found that the way to access other (docker) containers is to disable the services DNS. Note that we're also starting both the kind (docker) container and the dagger-engine (docker) container in the same (docker) network.

[vito]

Thanks! That helps a ton. That workflow would definitely break if I remove the feature flag, which is happening in #5557, but I don't want to leave you stranded. I can always just keep the feature flag, but in the long run we should figure out how to properly support your use case, since we don't want to have to maintain knobs like this forever.

There are some new mechanics in #5557 that should allow you to run everything in Dagger:

• It introduces static Service start and stop APIs, so you can start a long-running service independently of any clients.
• It introduces host-to-container networking, so you could run Kind in Docker Dagger and reach it from the host.
• It introduces container-to-host networking too, so you could point your tests at the same Kind cluster instance that you've exposed to the host.

The last part is a bit funny since it's tests => c2h => h2c => kind which ostensibly could be simplified to tests => kind, but it's the only way I can think of to allow two Dagger sessions to interact with different lifecycles (Kind stays running, test suite does not). We actually discussed the possibility of this in the (many) comments in #5557. Maybe cross-session networking is the use case?

Though now that I've taken a sip of coffee I guess you could also just keep running Kind in Docker like today and just use c2h networking to reach it from your tests. 😅

Does that sound reasonable?

[vbehar]

yes exactly, c2h networking should be enough. Ideally dagger-container to docker-container (so that we don't have to expose the docker containers ports on the host with random ports to avoid conflicts), but at least with c2h networking we can have something working.
thanks!