=== rangerpbzzzz is now known as rangerpb
[15:36] <rharper> smoser: http://paste.ubuntu.com/23124387/ -- looking at the event reporter output;  with the context manager, we get a start/finish for each manager;  however, for the stage runners, we don't seem to get the 'start' event;  in the paste, notice we have an extra finish, which is the other half of the 'start' of the module .. any idea why we don't get that first start event ?
[15:38] <smoser> how did you give it the config you wanted ?
[15:40] <smoser> rharper, ^ ?
[15:40] <smoser> i think maybe it didn't know of the config until after it started/
[15:41] <rharper> this is defaults
[15:41] <rharper> I'm parsing cloud-init.log output to recreate the records
[15:41] <rharper> if you look at cloudinit/cmds/main.py, it's the args.reporter which sets up the event stack with the name.
[15:52] <rharper> it does seem like the first event isn't "published" to the logger;  so maybe it's just getting chewed  somewhere in that util.log_time
[16:33] <smoser> rharper, try turning of rsyslog
[16:33] <smoser> in /etc/cloud/cloud.cfg.d/05_logging.cfg
[16:34] <smoser> comment out - [ *log_base, *log_syslog ]
[16:35] <rharper> ok
[16:35] <rharper> I'll give that a shot
=== rangerpb is now known as rangerpbzzzz
[17:34] <rharper> smoser: that didn't help; but I'll dig in and see what's up in main.py w.r.t the __enter__
[17:51] <rharper> 2016-09-02 17:48:13,667 - util.py[DEBUG]: Cloud-init v. 0.7.7 running 'init-local' at Fri, 02 Sep 2016 17:48:13 +0000. Up 1.0 seconds.
[17:51] <rharper> 2016-09-02 17:48:13,669 - util.py[DEBUG]: Writing to /var/log/cloud-init.log - ab: [420] 0 bytes
[17:51] <rharper> smoser: I think that clobbers the log file right after we've published the start event
[17:52] <rharper> so we miss the start event for each stage invocation, if that's true
[17:52] <rharper> let me remove that and see what it looks like
[17:59] <smoser> well, it does say 'ab'
[17:59] <smoser> but i guess quitei possibly athe first message was not flushed, and the filehandle probably still open
[18:05] <rharper> yeah;  still chasing it; it's just getting lost in logger;
[18:05] <rharper> I can see it getting published via the LogHandler and it's configured
[18:05] <rharper> we don't have this issue with curtin, so something is different
[19:30] <rharper> smoser: I don't understand how it can be fixed, but basically, since we don't "reconfigure reporting" until after the Init stage is created (and we call apply_reporting_config() with the initial cloud config ) then we lose the first set of reporting events (logging gets them but they're not ever emitted to /var/log/cloud-init.log)
[19:31] <rharper> it isn't terrible since not a log happens, but in terms of having matched pairs of events (start/finish); there's no point to starting the reporting event stack until after Init.stage2  is complete
[19:34] <smoser> rharper, yeah. i gues reconfigure_reporting could re-send the current one.
[19:56] <rharper> smoser: I don't know how we'd be able to replay previous events;