On Tue, 2021-02-23 at 11:18 +0100, Petr Menšík wrote:
Sure, this part is more complex. But only this part can fix this
problem
from inside the container IMO. Ie. we could fix it faster for any
involved parties.
I don't really run any container on any cloud service so this is just
my
guess. Who uses cloud-init to prepare the container? If it is used by
cloud provider, I would expect slow updates and conservative
behavior.
Even if we fix it immediately, how fast would appear on the service?
I
think the fix from within can be much sooner be used by users.
I think there might be a slight confusion here.
The use case I'm talking about doesn't involve any containers and how
DNS resolving is performed therein.
I'm thinking in terms of a vanilla Fedora Cloud image being used to
provision a new VM and cloud-init performing its configuration and
initialization.
This use case is currently broken (i.e. DNS resolution is broken),
since cloud-init doesn't properly configure DNS servers and fallback
DNS servers have been removed.
To fix this use case, we would just need to patch cloud-init as you
described in your 1. solution:
cloud-init would check the symlink and target of etc/resolv.conf. If it
points to /run/systemd/resolve/*, write DNS=x y into
/etc/systemd/resolved.conf.d/*cloud-init.conf
And then propose the patch to cloud-init upstream and include it in
Fedora's cloud-init package for Fedora 34.
As I see it, this could be fixed by Fedora itself and is not blocked on
any cloud provider or other external party?