20:04:35 #startmeeting log_wg 20:04:35 hi 20:04:35 o/ 20:04:35 Meeting started Wed Apr 8 20:04:34 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:36 And, it's not starting anyway. Grumble 20:04:36 hh 20:04:36 ?? 20:04:36 somebody posted on -infra that meet bot wasn't working. 20:04:36 Oh. Thanks bknudson 20:04:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:04:37 Well, first things first. I've finally got git working on my laptop and should be able to post the error code spec today (fingers crossed) 20:04:39 The meeting name has been set to 'log_wg' 20:04:56 Rockyg: yeah never got the e-mail 20:04:59 Meeting ended Wed Apr 8 20:04:35 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 20:05:01 Minutes: http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.html 20:05:02 Minutes (text): http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.txt 20:05:04 Log: http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.log.html 20:05:05 Meeting started Wed Apr 8 20:04:35 2015 UTC and is due to finish in 60 minutes. The chair is Rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:05:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:05:10 The meeting name has been set to 'log_wg' 20:05:12 Rockyg: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 20:05:17 A number of folks have gotten a rough draft of it. I'll send to anyone who wants a copy 20:05:31 Rockyg: send one to me :) 20:05:42 Do I have your email? 20:05:47 To me too, please 20:06:05 I thought I sent to jokke_ and ekudryashova already. 20:06:21 Rockyg: oh, darn ... yeah might be ... just PMing you 20:06:45 haven't been reading my personal mail box for few days 20:07:14 anyway, I think it will dovetail with some discussion with the API proposal 20:07:32 Rockyg: here it is nstarodubtsev dog mirantis.com 20:08:08 Great. Will send that out, shortly. Any comments before I manage to get it into gerrit are very welcome. 20:09:05 gimme a sec to get that out. And while I'm doing that, please rereview the api spec: #link https://review.openstack.org/#/c/167793/ 20:12:12 OK. Can't go out until I'm back on my corporate net, though -- have to go to the guest net to get to IRC :P 20:12:39 no worries :D 20:12:43 #topic API error code spec 20:12:45 send it out after 20:12:47 Any thoughts? 20:12:51 Rockyg: were you planning to change the spec based on the current comments? 20:13:35 I don't like it but I seem to be pretty much the only one 20:13:47 don't like what? 20:14:08 I was gonna present our spec, which has proj-component-number with database including description. The spec I am suggesting would let API set the middle value and follow the API spec for most of it. 20:14:15 the json dump on the api error proposal 20:14:59 jokke_: what would you prefer for an error response? 20:15:01 Yeah, I will be posting about some of it, too. Actually, a lot of folks don't like the json. And if we get Ops people reviewing, then they will chime in with us. 20:15:10 XML? 20:16:00 So, there are two thing in error response. What goes into code and what goes into log. Log should not be json. code should be json 20:16:07 bknudson: I prefer error message, not hundreds of lines of json about every error that might have occured 20:16:40 I expect it will usually be a single error. 20:17:16 is the error message translated? 20:18:04 bkhudson: Yes 20:18:25 I seriously think that logs are the place for that level of details. The client needs to know that a) something went wrong, b) what was it (hopefully on user errors blunt enough to fix it) c) some searchable identifier that can be used to google / contact support if one does not understand what went wrong 20:18:36 So, with the DB of error codes and general description, it makes general description easily translatable. Body of error would have instance and other stuff that might be less translatable 20:19:16 if the response has a request ID and you can find the log message for that request ID then that seems adequate. 20:19:56 but the JSON error document doesn't seem like overkill to me... sure seems to have extra fields, though. 20:20:05 that's again one of those things that lots of our big ops are not comfy to have that level of details in logs and now we're planning to return such with exception 20:20:19 e.g., status is redundant, and only one of id or code should be needed. 20:20:26 Speaking of request ids, there is also a review open in cross project on that #link https://review.openstack.org/#/c/156508/ 20:21:00 then all you have is id, title, description, and href, which seems like the right amount of info 20:21:27 where title and description are translated. 20:21:53 I think there are a number of issues being conflated in these discussions: Log messages vs errors, log message headers vs bodies, error codes vs errors, etc 20:22:14 oh, I thought we were talking about the error response 20:22:24 so did I 20:22:43 Ah. There's the rub. Error response != log message 20:22:57 correct 20:23:16 but the error response spec was the one you asked thoughts for ;) 20:23:45 Error response should be machine to machine. But it often needs to propagate out to log 20:24:16 if it's machine to machine then translation isn't going to help 20:24:46 as long as it's machine2machine only thing that needs to be sent over is the error code 20:24:53 bknudson: true, but some of the information propagated through to the log will need the translation 20:25:26 I thought the error response was going to the user... e.g., if I nova boot and it fails this would tell me what I did wrong. 20:25:30 jokke_: error code plus payload -- instance info, request id, etc 20:25:47 bknudson: that's what I was expecting as well 20:25:53 and would hopefully tell me what to do to fix it. 20:26:15 IMO that is really just for the user 20:26:37 Both: right, but it's API info, so it's aimed at developer (at least this spec) rather than end user 20:26:37 but even then it wouldn't need title and description, we could just stick with the message 20:27:13 is description the message? what's the difference? 20:27:26 but yeah I do dislike tons of json and bundling multiple errors into single response 20:27:49 Message is the payload. It is the descriptive string with instance specifics included 20:28:36 bknudson: why it needs topic ... the message should be what you need ... At least I don't want to read a novel encapsulated into json if I have typo in my passowrd 20:28:43 I think now you guys are getting why I think there is lots of confusion around this and log stuff 20:29:21 Rockyg: I do agree ... because next thing is that pprojects starts dump that json into logfiles 20:29:29 the CLI can render the error response any way it wants to... we can say it's just going to render the description of the first error. 20:32:00 Perhaps we can invite the API WG to one of our IRC meetings, or we get on their agenda to further discuss this? 20:32:28 if we want a log guideline then we should say that nobody wants JSON dumps in their logs. 20:32:30 bknudson: so what's the benefit of having all that json there wasting resources to be processed to the state where we are now, sending a single string message of what happened? 20:32:41 bknudson: +++ 20:32:42 bknudson: ++ 20:33:59 well I think we should take this to the spec review or mailing list, we probably had something else on the meeting agenda as well 20:34:36 I think we are getting closer to udnerstanding that we need to get a glossary of definitions to get everyone on the same page 20:34:36 jokke_: + 20:34:48 or at least I'd like to hear if there is any progress to score us a summit corner with table somewhere 20:35:26 Let's take it to the mailing list once the error code spec for logging is out. I can email most of you. I don't have bknudson's email, but can likely get it from launchpad. 20:35:38 :) 20:35:46 Rockyg: ++ 20:35:59 Rockyg: don't worry about emailing me... get it in gerrit and I can look at it there. 20:36:04 And, we can attend an APIwg meeting to further discuss 20:36:43 sounds like a plan 20:36:46 OK. Trying for today. I *think* i've got everything I need setup to make it happen. also, I'm putting it out with work still to be done, but the meat is there. 20:37:21 #topic request IDs 20:38:08 I'd like for folks to go over the #link https://review.openstack.org/#/c/156508/ and see what they think. 20:39:40 I would like to point out that the syslog RFC has lots of room for info both in headers and in payloads, and is flexible with intermediate systems passing log messages through, so we need to think about where the ids belong in a log message 20:39:40 ok, so that's out there now 20:40:58 jokke_: ?? is out there? 20:42:19 wow... this is proposing change the responses from ... JSON to a tuple? 20:42:53 Rockyg: that spec on OS-specs finally 20:43:21 Ah. Yeah. and it needs lots of comments. and some visibility. 20:43:34 Needs lots of work, I think. 20:43:49 there seems to be concerns about clients sending requests with the same request ID. 20:44:04 seems like if a client wants to screw itself then let them do it. 20:44:24 20:45:41 So, I believe that this proposal needs some people with a broader working understanding of projects and clients to help make the concept work. 20:46:09 It's possible/likely that the approach gets tossed, but the concept is implemented differently. 20:47:02 Perhaps just making the API WG aware of this and let them comment would be a good first step? 20:50:00 Any further comments? otherwise moving on... 20:50:23 #topic summit 20:51:13 I've suggested a general Ops session for log stuff. What happened in Kilo, what to focus on in Liberty, etc. 20:51:41 I'd also like to propose one for cross projects. Will do that ASAP 20:53:06 I'd also like to have a working session or two at the summit. The group seems small enough it could be adhoc 20:53:18 sounds good to me 20:53:43 sounds good to me too 20:54:00 Also, should we look for a meeting time earlier than the current one? I know this is late for most of you 20:54:17 and for me :) Sahara guys promise that they'll try to attend at least 1 meeting :) 20:54:47 Rockyg: 1 hour earlier will be fine for me 20:55:15 +1 for earlier meeting 20:56:01 Anyone here besides me and jokke_ going to be at the summit? 20:56:21 I plan to be at the summit... hasn't been totally confirmed yet. 20:57:48 Cool. For those not at the summit, if you want us focus on getting anything specific done/people talked to/recruited/etc. We'll have a topi in next weeks meeting to get your list of desires/needs 20:58:59 cool 20:59:19 I think we are pretty much at the end here. Let's make some stuff happen this week. and I'll call this baked;-) 20:59:40 #endmeeting