=== rangerpbzzzz is now known as rangerpb [13:39] this is pretty awesome. [13:39] import base64 [13:39] base64.encodestring("FOO") [13:39] TypeError: expected bytes-like object, not str [13:40] so... encodestring takes bytes and not a string. that makes sense. [14:23] smoser: I guess why I thought the timestamp in the log file was a syslog issue , is on xenial and yakkety, even the entries in syslog itself are missing resolution (journctrl --unit cloud-config) but maybe that's how we configure the logger ? [14:25] it appears that when we don't use syslog, we include a timestamp field in the log format; [14:25] rharper, so... recap [14:26] that implies to me that cloud-init using log_syslog relies on syslog to insert a timestamp (it does) [14:26] when cloud-init "comes up", it sets up python logging per 05_logging.cfg [14:26] but the resolution doesn't have subsecond in xenial and newer [14:26] i suspect that in xenial+ we're always going through rsyslog [14:26] I agree [14:26] and yes, when you log to syslog, its kind of pointless to add a timestamp [14:26] which is why I think rsyslog must have changed how it records timestamps [14:26] it would just be duplicate [14:26] right [14:27] (outside of the time delta between posting the message and rsyslog getting it) [14:27] right [14:27] but the resolution isn't sub-second; that seems wrong (sub optimal) [14:27] so it is possible that the default rsyslog configuration changed in xenial [14:27] and no longer logs subsecond when it used to [14:27] I can change rsyslog conf (there's a comment for high res ) [14:27] in /etc/rsyslog.conf [14:27] right, I'm hunting for that sort of change [14:28] I've not found it yet [14:28] can you verify that it was set the other way in previous releases ? [14:28] but I think I understand why we see the change, as you say, in trusty, rsyslog wasn't up yet and cloud-init uses the "Write to file" formatter with the timestamp [14:28] there's no "setting" [14:28] it's just the default [14:29] the rsyslog.conf is not different from trusty, xenial or yakkety (just versions of rsyslog) [14:29] but in trusty we almost certainly should have used syslog for later messages [14:29] (only cloud-init init should have gone "direct") [14:29] lemme look [14:29] yeah [14:29] I see it [14:29] it transistions to syslog [14:29] and drops the subsecond output =( [14:30] 2016-09-12 14:08:38,438 - util.py[DEBUG]: cloud-init mode 'init' took 0.209 seconds (0.00) [14:30] Sep 12 14:08:38 t1 [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.5 running 'modules:config' at Mon, 12 Sep 2016 14:08:38 +0000. Up 3.0 seconds. [14:31] so... [14:31] i'm really leaning towards harlow's suggestion [14:31] of dropping rsyslog unless configured. [14:32] "unless configured" meaning cloud-config specifically enabling it ? [14:32] our images clearly have a syslog configured === harmw_ is now known as harmw [20:59] smoser: nice! [21:00] now you need new $topic === smoser changed the topic of #cloud-init to: cloud-init 0.7.8 released 2016-09-12. 0.7.9 open. reviews: https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master/+activereviews [21:03] \o/ [21:38] jgrimm: re: EA, would cloud-init w/ ntp support work on CentOS 6 (python2?) [21:42] roaksoax, not tested for sure, but as far as python version i think should be ok (or fixable). rharper would talk more definitively to impl or other challenges ^^ [21:43] we need 2.7+ [21:43] this was capture in the NRE doc [21:43] w.r.t cloud-init requirements [21:43] centos has 2.6 [21:43] 2.6 *barely* works IIUC [21:43] rharper, +1 [21:44] that's a statement about general, not the ntp specifically i'm assuming [21:44] oh [21:44] sorry [21:45] right; there's not much to the ntp config module [21:45] I'd like smoser to speak up; but I really want to avoid having to support 2.6 in centos [21:45] yep, though your answer may be ultimately the right answer to the question. :) [21:46] yeah === rangerpb is now known as rangerpbzzzz