yahoo-eng-team team mailing list archive

[James Falcon <1762392@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3149

** Bug watch added: github.com/canonical/cloud-init/issues #3149
   https://github.com/canonical/cloud-init/issues/3149

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1762392

Title:
  timeout can be wrong if system time change

Status in cloud-init:
  Expired

Bug description:
  Seen on Xenial with a bad time on my hypervisor:

  Apr  9 08:57:03 localhost cloud-init[1242]: 2018-04-09 08:57:03,749 - url_helper.py[WARNING]: Calling 'http://10.81.0.218/latest/meta-data/instance-id' failed [0/5s]: bad status code [404]
  Apr  9 08:53:59 localhost ntpdate[1245]: step time server 10.81.0.218 offset -184.864291 sec
  Apr  9 08:53:59 localhost systemd[1]: Time has been changed
  Apr  9 08:53:59 localhost cloud-init[1242]: 2018-04-09 08:53:59,889 - url_helper.py[WARNING]: Calling 'http://10.81.0.218/latest/meta-data/instance-id' failed [-183/5s]: bad status code [404]
  Apr  9 08:54:00 localhost cloud-init[1242]: 2018-04-09 08:54:00,893 - url_helper.py[WARNING]: Calling 'http://10.81.0.218/latest/meta-data/instance-id' failed [-182/5s]: bad status code [404]

  I could just set the right time on my hypervisor but I believe there should be some mechanism in cloud-init to prevent this from happening.
  In my case, it just increase the timeout by 3 minutes but with a positive offset, it could wrongfully skip the timeout.

  A fix could be to prevent ntpdate to run until cloud-init is done but
  I am not sure if this is possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1762392/+subscriptions