On 2021-07-31 17:58:31 +0200 (+0200), Thomas Goirand wrote: [...] > I read the thread at the time. Isn't this a very opinionated way > to see things? When reading the thread, I didn't feel there was a > clear consensus. Opinionated maybe, though it's specifically meant to allow you to separately configure the domain for automated DNS integration in the provider. The upshot of the discussion though was to (thankfully) not break backward compatibility by doing something like forbidding anything which looked like an FQDN and merely accepting instead that it won't do what users expect if they try to tie in DNS zone management for their account. > Why would we then allow a single domain name? Let's say we were to > provide an OpenStack deployment for debian, and configured it with > "debian.net" as default domain, then what if I want a VM that > would use "debian.org" instead? This doesn't feel right at all... Well, on the user side of things, you could also always override this by appropriately configuring cloud-init in your userdata. You can also associate a domain with a network you create in Neutron I think? Though I've always felt that's weird since a server can have interfaces in more than one network and what happens if those have different domains when it comes to determining the FQDN? To be clear, I think this is a fairly significant shortcoming in the server data model. Maybe worth re-raising on the openstack-discuss ML given the "operator/user pain-points" theme for the next release cycle's goals. > Anyway, that's IMO not the issue. The issue is the (even short) > hostname not being resolvable with /etc/hosts not being edited by > cloud-init. Yep, that's why I mentioned the FQDN situation as being merely "somewhat related." That said, you can work around all of it by supplying cloud-init configuration in userdata. It's not the best user experience, but I find cloud-init's own defaults a little too aggressive for my tastes and basically always end up passing --user-data=cloud-init.yaml to override them anyway. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature