yahoo-eng-team team mailing list archive

[James Falcon <1273255@xxxxxxxxxxxxxxxxxx>]

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

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

** Changed in: cloud-init
       Status: Confirmed => 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/1273255

Title:
  wait_for_url doesn't account for system clock being changed

Status in cloud-init:
  Expired

Bug description:
  wait_for_url takes a 'max_wait' input, and then does:
   start = time.time()
   ...
    now = time.time()

  The problem is that when this runs early in boot, ntp (or anything
  else really) might have set the clock backwards.

  I'm looking at a console log that shows:
  2014-01-27 14:46:24,743 - url_helper.py[WARNING]: Calling 'http://169.254.169.2
  4/2009-04-04/meta-data/instance-id' failed [-16620/120s]: request error [(<urll
  compat_monitor0 console  

  Ie, the clock got set back 17000 seconds or something.

  Asking in # python, I was told that in python3.3 I could use
  'time.monotonic'.

  In python 2.X, it seems that reading /proc/cpuinfo might be my only
  option.

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