20:02:50 #startmeeting log_wg 20:02:51 Meeting started Wed May 27 20:02:50 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:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:54 The meeting name has been set to 'log_wg' 20:03:28 jokke_: bknudson dhellmann who am I forgetting? 20:03:37 hi 20:04:08 Hey, there! 20:04:42 o/ 20:05:06 First off, I want to thank dhellmann for the new release of oslo.log 20:05:26 Thanks, dhellmann! 20:05:44 Next, a recap of discussions at the summit 20:06:01 #topic Thanks for new oslo.log! 20:06:09 what did dhellmann do? 20:06:33 it's got versionutils, so we should be able to use that in keystone 20:06:45 bknudson: yep it's in there 20:07:01 oh, dims_ did that yesterday 20:08:23 also, got a deprecation message in, global requirement updates 20:08:35 fixed a TRACE/ERROR issue 20:08:47 fixed pep8 errors. 20:09:01 Improved docs around versionutils 20:09:24 fixed syslog stuff 20:09:24 cool 20:09:55 741 insertions, 711 deletions. 20:10:21 onwards. 20:10:31 #topic Summit Rehash 20:12:02 we now have three competing specs for requester ID. The second and third are cool because there are changes only in oslo.log and in the related project, I think. 20:12:51 trying to find the links. But, I have a question/concern for dhellmann, bknudson and other developers. 20:13:21 hmm-m ... I was reading that e-mail today and I think I'm bit confused around those 20:13:31 second review uses auth_token from Keystone. I get that one. 20:13:48 auth_token middleware 20:14:01 Third review (don't know if it's there yet) uses ID from os_profiler 20:14:11 https://review.openstack.org/134839 20:14:19 Thanks! 20:14:23 os_profiler kind of covered this already so it makes sense to use whatever they did. 20:14:40 rather than invent something new 20:14:53 maybe the request ID part could be split out of os_profiler 20:15:22 oh, os profiler isn't accepted anyways 20:15:26 Well, if os_profiler can't be turned off, I can see where this would be ok. 20:15:37 bknudson: the spec isn't approved, but some projects have started adding os-profiler 20:15:53 But, I could see ops guys not wanting the extra bits of a profiler running during production 20:15:56 actually it's os-profiler that should be able to use whatever request ID scheme that's actually accepted 20:16:00 we can make it possible to turn off the profiler data collection part, but keep the request id stuff always on 20:16:17 yeah, I don't really care what we use as long as we pick one that works for all of our current use cases 20:16:33 dhellmann: that would make me happier. It just seems a wierd way to architect for request ids 20:16:53 bknudson: I do agree, the req-id should be consumed by os-profiler, not other way around 20:17:32 Should we discuss this in the spec reviews, or take it to the mailing list? 20:18:35 I mean, it's nice that it's being taken on by the os-profiler, but I'm pretty sure that Keystone is a better fit for identity/security/architecture reasons 20:18:57 there was a mailing list thread, we should probably follow up there 20:19:12 ++ 20:19:15 Great. 20:19:23 Thanks. 20:19:28 http://lists.openstack.org/pipermail/openstack-dev/2015-May/064842.html 20:20:12 and related to those 3 Solutions, the message from ops was really loud and clear in the summit, they want the option 3 where a sindle ID follows all the way 20:20:16 Yeah. We never did get to circle back to Abhishek 20:20:34 jokke_: yeah, that's unlikely to be accepted by devs though 20:21:07 jokke_: for logs, yes, with a hop count. so the first one always has to be passed, but others could come and go? 20:21:24 dhellmann: I think we should look into mirror on that and think to whom these things are developed for 20:21:35 some requests fork, and you wouldn't be able to keep track of the separate threads if you only have one id 20:21:55 jokke_: that solution just doesn't work technically, it's not a preference situation 20:22:58 dhellmann: what does not work on it ... if we create id when it's not in request and pass it forward for any request created by the service, I don't see what technically would block it 20:23:00 the os-profiler model takes care of the threading, so we should look closely at what they do 20:23:04 dhellmann: jokke_ I think that's why we need to specify what gets passed in the log message, vs what is getting passed around. We should always pass the initiating requestID around, and sometimes others. 20:23:24 But, we should only pass the initiating request ID to log messages? 20:24:03 jokke_: (a) we can't trust the incoming request id as being unique (b) if nova makes several calls to another backend service like neutron, those each need a separate request id because they might happen in parallel 20:24:17 I think we do need to look at the threading design in os-profiler 20:25:45 can we take this as an action item to investigate further through code review and circle back next week? Does that make sense? 20:26:12 dhellmann: the (a) is irrelevant and (b) has good point ... I think way bigger problem is how big ID field we need if we start generating new IDs for every interraction ... good couple of dozen of them for one request and we're pretty quickly out of the uniqueness in big deployment anyways 20:26:20 Rockyg: it would be good to have someone get all of the folks with proposals together to try to unify them 20:26:29 I would want to know how deep/often the forking happens 20:26:30 dhellmann: ++ 20:26:35 ++ 20:26:52 #action contact review authors and set an IRC meet 20:27:18 jokke_: if you let me pass "jokke_" as my request id with every client call, you'll very quickly find that your logs are useless 20:27:47 dhellmann: only regarding your requests and you're just shooting yourself into foot with that 20:29:13 dhellmann: and that was pretty loose quote from the ops during the session when we were talking about that 20:29:25 I think it would be good if we could get an example log flow and walk through it to see what happens. In parallel to getting the three devs together 20:30:40 I'll ping the three devs, and the large system ops who was in the session to see what I can arrange. 20:31:01 Rockyg: thanks 20:31:13 Will set up an etherpad for discussion and post it to the ML thread 20:31:21 sounds good 20:31:32 Rockyg: I'll get a contact from our ops side for you as well as I think I didn't see any of our guys there 20:32:10 Anything else we should bring up from the summit? Lots of oslo.log stuff, but I don't remember anything controversial about it :-) 20:32:25 no, not really 20:33:12 etherpad of the oslo.log session - https://etherpad.openstack.org/p/YVR-oslo-log-plans 20:33:12 the spec to clean up the default handling has already been approved for oslo, so I'll start working on that in a few weeks when some of the other work I'm doing is wrapped up 20:33:36 dhellmann: anything I can help with there? 20:33:42 Oh, shoot. Just remembered. I likely won't be on next week. Need someone else to run the meeting just in case. I'll be in Boston for my college reunion 20:34:28 thanks for the link, dims_ 20:35:00 #link https://etherpad.openstack.org/p/YVR-oslo-log-plans 20:35:03 jokke_: I have a pretty good idea of what's needed, but I'll want reviews 20:35:30 And also a heads up. The primary backers of the os-profiler review are both very *strong* personalities. 20:35:53 dhellmann: drop me a line here or e-mail if there's something you want a hand with ... 20:36:02 jokke_: sounds good, thanks 20:36:16 dhellmann: I'll try to find the time for it in reasonable notice 20:37:00 bknudson: any chance I can get you to discuss this discussion with jamie lennox? He's the author of the second. 20:37:25 And, jokke_, how about abhishek? 20:37:33 we talked to jamielennox at the summit 20:38:05 bknudson: yeah. Just an update , or make sure he's following the ML thread 20:38:18 I'll also ping. And thanks for the IRC handle 20:38:21 Rockyg: I'm sure Abhishek is up for it ... I certainly am 20:39:26 Cool. We need to make sure we have some serious devops also in the mix. Get the design down well, first, before end results start appearing. 20:39:41 OK. next topic 20:39:50 #topic open discussion 20:39:58 anything to talk about? 20:40:09 that is anything else? 20:40:27 dhellmann: you can add me to the reviews for the logging changes. 20:40:29 I'll get on ops docs when I get back from Boston. Back on 6/8 20:41:17 And I'll try to actually summarize the sessions and results within a week or two this time. 20:41:20 bknudson: will do; I'm going to try to finish the namespace work before I start those 20:41:31 Rockyg: drop me e-mail before next weeks meeting if you have some updtates ... I can chair it if we have something that needs attention 20:41:48 jokke_: ok, thanks 20:42:37 Anything else we need to put on the table, or should we call this a wrap? 20:43:28 I don't have anything at least ... still trying to sort all my mental notes from the summit 20:43:33 * dhellmann has nothing to raise 20:43:46 and survive from the jetlag ... this time around seems to be nasty one 20:44:44 dhellmann, dims_: Also, I wanted to make sure you know that nkrinner is interested in working on oslo stuff 20:45:04 Rockyg: great! 20:45:09 Rockyg: nkrinner: welcome! 20:45:24 I got that right, nkrinner? 20:45:27 yeah, but i still have not started yet... 20:45:51 These guys can point you at something you can wrap your brain around to start you. 20:45:55 i have some other things to finish first, but i expect to start actively looking at oslo from next week on 20:46:28 Cool. then, it's a wrap 20:46:31 nkrinner: just hop onto #openstack-oslo 20:46:40 dims_: thanks! 20:46:51 #endmeeting