[13:39] <smoser> this is pretty awesome.
[13:39] <smoser> import base64
[13:39] <smoser> base64.encodestring("FOO")
[13:39] <smoser> TypeError: expected bytes-like object, not str
[13:40] <smoser> so... encodestring takes bytes and not a string. that makes sense.
[14:23] <rharper> 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] <rharper> it appears that when we don't use syslog, we include a timestamp field in the log format;
[14:25] <smoser> rharper, so... recap
[14:26] <rharper> that implies to me that cloud-init using log_syslog relies on syslog to insert a timestamp (it does)
[14:26] <smoser> when cloud-init "comes up", it sets up python logging per 05_logging.cfg
[14:26] <rharper> but the resolution doesn't have subsecond in xenial and newer
[14:26] <smoser> i suspect that in xenial+ we're always going through rsyslog
[14:26] <rharper> I agree
[14:26] <smoser> and yes, when you log to syslog, its kind of pointless to add a timestamp
[14:26] <rharper> which is why I think rsyslog must have changed how it records timestamps
[14:26] <smoser> it would just be duplicate
[14:26] <rharper> right
[14:27] <smoser> (outside of the time delta between posting the message and rsyslog getting it)
[14:27] <rharper> right
[14:27] <rharper> but the resolution isn't sub-second; that seems wrong (sub optimal)
[14:27] <smoser> so it is possible that the default rsyslog configuration changed in xenial
[14:27] <smoser> and no longer logs subsecond when it used to
[14:27] <rharper> I can change rsyslog conf (there's a comment for high res )
[14:27] <rharper> in /etc/rsyslog.conf
[14:27] <rharper> right, I'm hunting for that sort of change
[14:28] <rharper> I've not found it yet
[14:28] <smoser> can you verify that it was set the other way in previous releases ?
[14:28] <rharper> 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] <rharper> there's no "setting"
[14:28] <rharper> it's just the default
[14:29] <rharper> the rsyslog.conf is not different from trusty, xenial or yakkety (just versions of rsyslog)
[14:29] <smoser> but in trusty we almost certainly should have used syslog for later messages
[14:29] <smoser> (only cloud-init init should have gone "direct")
[14:29] <rharper> lemme look
[14:29] <rharper> yeah
[14:29] <rharper> I see it
[14:29] <rharper> it transistions to syslog
[14:29] <rharper> and drops the subsecond output =(
[14:30] <rharper> 2016-09-12 14:08:38,438 - util.py[DEBUG]: cloud-init mode 'init' took 0.209 seconds (0.00)
[14:30] <rharper> 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] <smoser> so...
[14:31] <smoser> i'm really leaning towards harlow's suggestion
[14:31] <smoser> of dropping rsyslog unless configured.
[14:32] <rharper> "unless configured" meaning cloud-config specifically enabling it ?
[14:32] <rharper> our images clearly have a syslog configured
[20:59] <rharper> smoser: nice!
[21:00] <rharper> now you need new $topic
[21:03] <jgrimm> \o/
[21:38] <roaksoax> jgrimm: re: EA, would cloud-init w/ ntp support work on CentOS 6 (python2?)
[21:42] <jgrimm> 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] <rharper> we need 2.7+
[21:43] <rharper> this was capture in the NRE doc
[21:43] <rharper> w.r.t cloud-init requirements
[21:43] <rharper> centos has 2.6
[21:43] <rharper> 2.6 *barely* works IIUC
[21:43] <jgrimm> rharper, +1
[21:44] <jgrimm> that's a statement about general, not the ntp specifically i'm assuming
[21:44] <rharper> oh
[21:44] <rharper> sorry
[21:45] <rharper> right;  there's not much to the ntp config module
[21:45] <rharper> I'd like smoser to speak up; but I really want to avoid having to support 2.6 in centos
[21:45] <jgrimm> yep, though your answer may be ultimately the right answer to the question. :)
[21:46] <rharper> yeah