We also need to disable the update_etc_hosts module, otherwise the /etc/hosts contents are reset.
https://code.launchpad.net/~paride/autopkgtest-cloud/+git/autopkgtest- cloud/+merge/464614 Notes: * The hostname and cloud-init upgrades I mentioned in an earlier comment were red herrings. * I tried telling cloud-init to leave /etc/hosts alone by setting `manage_etc_hosts: false` in `/etc/cloud/cloud.cfg`, but that didn't work. The user-data we get from ps5 has an explicit `manage_etc_hosts: true`, so I guess the user-data can override cloud.cfg. * I really struggled reproducing the issue. Maybe it's racy (sometimes cloud-init didn't get to update /etc/hosts in time, and we managed to install postfix before that)? But this would be a really slow race. Or maybe there are details of the ps5 infrastructure that I'm missing (different endpoints serving slightly different user-data? Or: user-data settings being changed and then rolled back, so I was trying to reproduce on an unstable ground?). I don't know. In general I think disabling the module makes sense. -- You received this bug notification because you are a member of Canonical's Ubuntu QA, which is subscribed to Auto Package Testing. https://bugs.launchpad.net/bugs/2019472 Title: Trailing dot in fqdn of ps5 VMs regresses some tests (e.g. postfix) Status in Auto Package Testing: In Progress Bug description: On ps5 amd64 VMs (lcy02) we have that: $ hostname --fqdn adt-paride-mantic-postfix.openstack.prodstack5.lan. Note the trailing dot. This causes regressions in some packages, see for example LP: #2019195. Ideally we should fix the regressed packages (the trailing dot is technically correct), but it makes sense to workaround the problem while the packages are getting fixed. Some possibilities are: (1) Remove `manage_etc_hosts: true` from the cloud-init user-data used by the create-nova-image-new-release script. This should prevent the hostname to be set to the name advertised by openstack, and left to the static string 'autopkgtest'. I did some git archeology and manage_etc_hosts initially came from this snippet: # unbreak my server option :-( userdata=`mktemp` trap "rm $userdata" EXIT TERM INT QUIT PIPE /bin/echo -e "#cloud-config\nmanage_etc_hosts: True" > $userdata and that was the *only* use of user-data back then. Looks like it was a workaround for some issue? In any case I can't be sure that disabling manage_etc_hosts won't cause other issues. (2) Remove the trailing dot in /etc/hosts using the setup-canonical.sh script, e.g. sed -Ei '/^127\.0\.1\.1 /s/([a-z])\. /\1 /' /etc/hosts I don't think this can be racey with cloud-init reconfiguring the hostname because testbed-setup removes cloud-init. Cons of this approach: very hacky. We ask cloud-init to manage /etc/hosts (via manage_etc_hosts), but then mangle it manually (not nice). To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/2019472/+subscriptions -- Mailing list: https://launchpad.net/~canonical-ubuntu-qa Post to : canonical-ubuntu-qa@lists.launchpad.net Unsubscribe : https://launchpad.net/~canonical-ubuntu-qa More help : https://help.launchpad.net/ListHelp
