20:04:13 #startmeeting log_wg 20:04:14 Meeting started Wed Sep 9 20:04:13 2015 UTC and is due to finish in 60 minutes. The chair is Rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:04:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:04:17 The meeting name has been set to 'log_wg' 20:05:06 jokke_ got us a workroom session 20:05:22 good that we got one. 20:05:31 we have made a little progress 20:05:44 still lots to do 20:06:46 yup 20:07:29 just a sec... 20:08:10 o/ 20:08:14 sorry for being bit late 20:08:29 OK. I'm back! 20:08:41 #topic Tokyo 20:09:04 Again, jokke_ got us a room...wanna elaborate? 20:09:36 yeah, we got working session for Wednesday noon (just before lunch) 20:09:53 It's small room, but I assumed that we will survive with that 20:09:53 kewl. 20:10:23 small is fine. 20:10:32 so as rocky told me we were bundled together in the ops side, now we have one in the dev side as well 20:10:39 how small? 20:10:41 hopefully we manage to get bit more traction 20:11:27 So, in prep for that , I plan on joining the oslo docs sprint for liberty. 20:11:28 hopefully it won't conflict with a keystone session 20:11:53 #action document the log config options during doc sprint 20:12:14 #action document the loggin system architecture during olso doc sprint 20:12:36 we should get all the log config options in their own section 20:12:44 Let's hope. I'd love to get keystone as part of the focus for the dev log woking session... 20:12:45 rather than prefix with logging_ 20:12:53 It was close call there was just few slots left and it was day before closing for those rooms. Also as we didn't have any actual schedules, we can just hope it's not overlapping too much 20:13:40 and I'm not sure what size room it is, but iirc in Vancouver we were told that the smaller working session rooms would be about the same as the small rooms in the 3rd floor in vancouver 20:13:54 so <20 people 20:14:12 I think now is the time we let ttx know where we *don't* want conflicts. They have the number of rooms figured out, now they start on who gets what when 20:14:18 everybody talks about usability but then when it comes to assigning summit sessions... 20:15:02 so do we have other avoidances than oslo, keystone, glance? 20:15:11 It's all fun and games until the flying monkeys attack... 20:15:40 That and API wg 20:17:16 bknudson, so, you mean configs in doc, requirements.txt or ....? for all in one section? 20:17:35 well API wg is cut from the same pool so I assume no overlapping 20:17:38 in the .conf file, put them in a section 20:17:54 Definitely! 20:19:07 If we get the full list, we can see if they'll let us put a section is that is all commented out, but with basic info 20:20:22 I know they're trying to reduce the number of .conf files, also, so we should definitely clean up those, too. 20:21:10 I wish I had an intern. So much more of this would have already been done. 20:21:21 Rockyg: :) 20:21:33 or just time to do the stuff :) 20:21:46 bknudson, any chance I can get you tovolunteer to review the .conf file and make a suggestion? 20:22:43 so one tihng ref Tokyo we still need to do is to give topic to our session 20:22:46 jokke_, yeah, time. I'm supposed to be at a two day meeting in China on 9/23-24 20:23:20 Rockyg: I'm signed up for the oslo doc day 20:23:29 that's this week? 20:23:30 sounds great ... makes really sense to fly all the way there for 2 days 20:24:05 then back to tokyo a month later... 20:24:17 yup 20:24:30 btw have you everything booked for Tokyo? 20:24:40 bknudson, no, in a week and a half. Don't even have a visa yet 20:24:45 Just a hint the close by hotels are starting to be sold out 20:24:49 got a room, not a flight 20:25:38 I'm all booked for tokyo summit 20:25:48 So, here's what I'd love to have for a dev work session for Tokyo... 20:26:02 good stuff same here got everything sorted Monday I think 20:26:19 -- a bunch of bps for stuff for liberty 20:26:35 a list of bugs we want fixed 20:27:04 reminder, we have 40min 20:27:16 40 mins is never enough 20:27:17 -- a bp/spec for error code placeholder in log message structure -- flexibility 20:27:46 the last one is because it appears easier to get the place holder than have folks decide on what an error code looks like. 20:28:19 Personally I think the best use for that time would be to try to get as much interested folks into same room as possible and trying to get this meeting to be bit more that 3-4 of us talking weekly 20:28:22 we could also try to get together at other times if we're not too busy 20:29:19 I'd really like to get some folks together to put down common log line format which would get support in the dev community 20:29:20 Yes, I get in early and usually don't have evening stuff before it all starts 20:29:50 we've been talking with ops about that few times and we have it somewhere, now we need to get devs meeting the ops with implementation ;) 20:30:23 ops saying they need better logs might help 20:30:29 #action Rockyg to talk with tom about ops log session being scheduled before dev session 20:30:36 or devs saying we need better logs might help, too. 20:30:36 The Lunch room is going to be available for ad-hoc round table sittings outside of lunchtime 20:31:13 bknudson, we have to put up a strawman for dev. most of them don't deal well with ambiguity 20:31:33 I agree we need to be more specific than "better" 20:31:38 bknudson: yes and no ... they are screaming that, but "We need better X, Y, Z" is not actionable so nothing gets done ... we need exact improvements 20:31:50 although it works for trump to say his obamacare replacement will be something terrific. 20:32:18 You know trump's uncle was a prof at MIT 20:32:49 How about we start an etherpad and start putting up a format? 20:33:17 #topic meeting time change and getting more participants 20:33:19 what's wrong with the current format? 20:33:57 bknudson, option to have placeholders for missing optional fields.... 20:34:52 and exactly placeholders so - if that field is not provided so that the count of fields will be standard 20:34:56 btw, my change for keystone to log request ID is merged for L: http://logs.openstack.org/11/218511/4/gate/gate-tempest-dsvm-full/9de3975/logs/apache/keystone.txt.gz?level=INFO 20:35:13 would also be nice to make the order of fields the same across projects 20:35:14 bknudson: I saw it, good stuff 20:35:41 kewl 20:35:50 I'll have to read it 20:36:03 #link http://logs.openstack.org/11/218511/4/gate/gate-tempest-dsvm-full/9de3975/logs/apache/keystone.txt.gz?level=INFO 20:37:32 also when uuid is used for identification, we should be consistent on number of bits used 20:38:23 I don't think we do anything with the default log format. 20:38:23 so what you see in the log there is what you get with openstack by default 20:38:24 So, maybe an etherpad on list of bugs, specific features/fixes, and docs 20:40:00 Yeah. That looks good. Maybe we just advertise that the default is good to all the devs through devref? Don't mess with it unless you *know what you're doing!"? 20:40:42 could also say "you don't know what you're doing" 20:41:17 I think one of the docs we really need is one describing what devs should log and how. One reference that is linked from all the projects' devrefs 20:41:27 bknudson, ++ ;-) 20:41:27 btw - my opinion is that the log format isn't really all that good. 20:41:44 there are fields there that really only apply to nova. 20:42:15 I think one of the dashes there is the instance ID ... which doesn't apply to keystone 20:42:35 There is a spec for app agnostic logging. It's in the olso specs, I think. Lemme check... 20:45:53 here's the bp: https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters 20:46:07 old skool bps. 20:46:42 https://review.openstack.org/#/c/95281/3/specs/juno/app-agnostic-logging-parameters.rst 20:46:47 it's merged since juno 20:47:08 jup 20:47:14 Yup. following the trail, though is long and sucks. 20:47:49 So, read up on that and if you have any comments/changes/etc, submit them as an amendment to the spec. 20:48:35 sounds like a plan 20:49:16 http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/_options.py#n101 still has instance 20:50:29 Here's the readable format of all the oslo specs: #link http://specs.openstack.org/openstack/oslo-specs/ 20:51:04 Rockyg: not all, approved 20:51:13 Yup. 20:52:04 And I need to suggest to docs or infra or someone that there needs to be an alternate organization for specs so that all current ones for each project are in one place 20:52:54 instead of "here are the current specs...but don't forget the old ones because they apply, too, even though they aren HERE" 20:53:12 so my initial change was just to get the request ID in the logs, I've got a separate change to get the rest of the user info in the logs. 20:53:40 this stuff - http://git.openstack.org/cgit/openstack/oslo.context/tree/oslo_context/context.py#n43 20:54:54 check out: https://blueprints.launchpad.net/oslo.log/+spec/user-identity-format-flexibility and the spec that goes with it 20:55:17 keystone doesn't need identity format to be flexible. 20:55:22 That actually got in and I want to use that for Error Code flexibility 20:55:28 actually, I'd prefer it wasn't flexible. 20:55:57 since I don't want people who "know what they're doing" but don't actually know what they're doing to change it. 20:56:14 Ah, but what that is is the place holder to put the stuff. If ops says "we want it this way" we can get it pinned down. 20:56:19 for example, whoever came up with '{user} {tenant} {domain} {user_domain} {p_domain}' doesn't know that we renamed tenant to project. 20:57:16 or does know, but doesn't care :P 20:57:41 or does know but got slapped by someone who doesn't know 20:58:38 Plus, project is overloaded, so for documentation sake, maybe they are saying "we know what tenant means and it goes with p_domain but all the overloading of terms is confusing" 20:58:53 ++ 20:59:11 how does anybody know that p_domain goes with tenant? 20:59:22 Exactly. 20:59:23 I know because I've been working on keystone for a long time. 20:59:32 I have no idea what p_domain is ;) 20:59:51 But how does anyone one know that project replaces tenant and isn't talking about neutron or nova or.... 21:00:26 that's a good question why keystone chose "project" which was already in use. 21:00:48 not sure what was wrong with tenant. 21:01:06 there was probably osme loud individual who was just persistently against every other proposal 21:01:26 that's how most of the bad OpenStack decisions seems to be made ;) 21:01:30 well, it makes sense in its own way, especially if you consider different teams work on different projects and each project wants its own cloud 21:01:52 nova wants its own cloud? 21:01:55 well we're out of time 21:02:21 no, but the marketing team wants its own cloud;-) 21:02:31 #endmeeting