canonical-ubuntu-qa team mailing list archive

[Paride Legovini <2019472@xxxxxxxxxxxxxxxxxx>]

I still can't reproduce the issue, but I have some more data points.
Taking [1] as an example of a "bad" run, we can see that:

 - /etc/hosts is mangled via sed (not visible from the logs)
 - hostname (the package) and cloud-init get upgraded
 - the system reboots

*something* in caused the `sed` to not have effect (/etc/hosts got
rewritten? by what? the cloud-init upgrade caused some sort of race?). I
tried downgrading the packages, but still couldn't reproduce the
problem.

Maybe the `sed` should be moved to autopkgtest --setup-commands-boot.

For reference, [2] is the postfix bug about it not being to handle the
trailing dot.

[1] https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/m/mime-construct/20240412_050518_cab97@/log.gz
[2] https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/2019195

-- 
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:
  Incomplete

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