20:02:06 <rockyg> #startmeeting log_wg
20:02:07 <openstack> Meeting started Wed Nov 11 20:02:06 2015 UTC and is due to finish in 60 minutes.  The chair is rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:10 <openstack> The meeting name has been set to 'log_wg'
20:02:29 <Jokke_> I did not kick the meeting off yet as I didn't know if anyone else was coming :)
20:03:04 <rockyg> Agenda:  Review of Summit results; Action items from Summit; Discussion
20:03:43 <rockyg> hey, that's ok.  I'm slow.  Work killed my access to the outside net, so I have to use webchat :P
20:04:15 <Jokke_> ouch, that's handy
20:04:18 <rockyg> #topic Review of Summit
20:04:49 <rockyg> We managed to get a fair amount agreed upon.
20:05:43 <Jokke_> well ...
20:06:11 <rockyg> Dynamic reconfiguration of config options for logging and other changeable options was agreed upon and is already being worked
20:06:29 <Jokke_> I think we agreed to swift focus
20:06:41 <Jokke_> yes, oh nice
20:07:27 <rockyg> format for propagating request-id into log messages was agreed upon mostly.  A spec is needed to move this forward
20:07:46 <rockyg> Swift focus?
20:09:09 <Jokke_> error code discussion
20:10:03 <rockyg> Agreed to work on getting log message levels more consistent across/within projects before pushing error codes.  Need to socialize need for lots of bugs being filed
20:10:28 <Jokke_> yes
20:10:29 <rockyg> Jokke_: still not understanding.  Not enough coffee
20:12:37 <Jokke_> that was my point, we have been pushing error codes for a year and we decided to swift our focus elsewhere
20:13:05 <rockyg> Oh! shift! twice typo'ed
20:13:34 <rockyg> Anything else from Summit?
20:13:45 <Jokke_> Oh .... I think I'm the one needing coffee
20:15:04 <Jokke_> I think those were the most important bits
20:15:05 <rockyg> :D
20:15:32 <rockyg> Ok.
20:15:49 <rockyg> #topic Action items from summit
20:16:20 <rockyg> #action write oslo.log spec for request-id inclusion in log messages
20:17:11 <rockyg> #action post bug requests to operators ML and user group ML
20:17:11 <Jokke_> did I miss that discussion, mind to give me tl;dr of what was agreed?
20:17:24 <Jokke_> the request-id one
20:17:27 <rockyg> Yup. you missed it.
20:17:45 <rockyg> It was good.  And hard.  It's amazing how dense developers can be.
20:17:52 <rockyg> So, recap:
20:19:13 <rockyg> #info  RequestID would have three fields [original requestID] [current RequestID][next RequestID] or similar.
20:20:02 <rockyg> #info original requestID is the id of the client call that starts the chain of events.  It is constant until the chain is completed or errors out
20:21:31 <rockyg> #info Current RequestID is the id that is generated when the original request is has been handed off in the API transition
20:21:49 <Jokke_> so how do we provide that? are we going to finally agree that the service accepts request-id as part of the query?
20:22:19 <rockyg> #info Next RequestID is the requestID for the handoff to the next API interaction
20:23:21 <rockyg> So, the APIs should generate the ID as the handoff occurs.  If need be, the list might endup [orig][last][current].  Not sure, but still a linke list
20:23:52 <rockyg> The requestID spec implementation will make the local requestID generation happen.
20:24:19 <Jokke_> that's not problem, that's there already
20:24:29 <Jokke_> the original one interests me
20:24:50 <rockyg> requestID spec is also implementing the generation in the clients
20:25:56 <Jokke_> k
20:26:09 <rockyg> The guys who wrote the spec were there.  They liked getting these into the log messages.  The hard part will be getting the log message generated at handoffs, but since the spec writers are the implementers, they can add the log message calls, too.
20:27:04 <rockyg> I think we are going to suggest using the syslog keyed list field for this.
20:27:40 <Jokke_> those logs are going to be horrible to read for humans
20:28:01 <Jokke_> 3 UUIDs on every line :(
20:28:29 <rockyg> Nah.  Only three extra ids.  What we should do is get the requestID size limited to something reasonable.
20:29:22 <Jokke_> that's my point. Req id is UUID (current implementation)
20:29:37 <rockyg> Uh, requestID can be a sized UUID, so it could be UUID4 or UUID8 or UUID16 rather than 32.  But I think that's a separate spec.
20:30:33 <rockyg> Or maybe a mod to the requestID spec.
20:31:16 <rockyg> What we should do is make the size configurable, but consistent.  Set it once for the whole cloud.
20:31:37 <Jokke_> that would be gr8
20:31:59 <rockyg> Which would mean that we'd need to make sure the uuid generator is part of an oslo lib.
20:32:14 <rockyg> And that all generation is done by the lib.
20:32:33 <rockyg> I think we are working through the spec issues :-)
20:32:38 <Jokke_> and each service advices their clients which size req-id to generate
20:33:01 <rockyg> I bet the ops would love to have a configurable UUID size
20:33:46 <rockyg> Small clouds wouldn't need as big of uuids as large clouds.  And, we could provide guidance on how to size in the admin docs
20:34:15 <Jokke_> back in 3
20:34:21 <rockyg> np
20:36:38 <rockyg> I took this chance to get some coffee ;-)
20:37:39 <Jokke_> sorry bout that
20:38:06 <rockyg> not a problem.  I got coffee
20:38:13 <Jokke_> :)
20:38:58 <rockyg> ok.  so, have we beaten this horse enough?
20:39:46 <Jokke_> yeah, I thik it's ready for glue factory
20:40:02 <rockyg> I won't be able to get to start writing the spec until next week at the earliest.  I have lots of ML catch up to do and have to finish off some expense reports and summit summaries
20:40:11 <rockyg> Good one!
20:41:09 <rockyg> #action socialize the need for bugs to get the log message levels consistent
20:41:48 <rockyg> we could do this a number of ways.
20:42:29 <rockyg> I'm wondering if we should try for getting a good number of bugs together, then analyze those to make the guidelines better
20:42:50 <Jokke_> that wouldn't hurt
20:43:17 <rockyg> I think the ops know better what they need/want than the devs do.
20:43:39 <rockyg> I wonder if we can get a bugs sprint with the ops, just taking an hour or two to file bugs on messages
20:44:58 <Jokke_> I'd like to get started with having folks filing those their filter lists as bugs
20:46:04 <rockyg> Yup.  and it might be easiest to schedule a time when a bunch of them could do it together.  Also might reduce duplication that way.
20:46:46 <rockyg> Maybe we should consider a weekly sprint - focus on one project per week?  If we need more than that as a start, we could schedule a second session
20:46:54 <Jokke_> that could be
20:47:32 <rockyg> I think I could get some Rackspace and som GoDaddy participation on this.  Maybe more.
20:48:23 <rockyg> I think we may have a strategy.
20:48:41 <Jokke_> good!
20:49:24 <rockyg> #topic open discussion
20:50:19 <rockyg> What I'd love to see also is a bug against every stackdump that happens when running.  Every one should be eliminated and replaced by an error log message
20:51:10 <rockyg> But maybe we should save that for the error codes timeframe.  Then, each new log instance would get that code at the same time.
20:51:40 <Jokke_> that could be
20:53:33 <rockyg> Well, let's see what we can make happen this cycle.  Changing log levels for messages should be low hanging fruit.  And with more projects actually scheduling bug triage time, this stuff could get done.
20:54:05 <Jokke_> yeah, hopefully we get the ops activated
20:55:22 <rockyg> yup.
20:55:24 <Jokke_> anything else?
20:55:33 <rockyg> So, how about we call this early?
20:55:38 <Jokke_> ++
20:55:45 <rockyg> #endmeeting