20:04:35 <Rockyg> #startmeeting log_wg
20:04:35 <bknudson> hi
20:04:35 <jokke_> o/
20:04:35 <openstack> 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 <Rockyg> And, it's not starting anyway.  Grumble
20:04:36 <Nikolay_St> hh
20:04:36 <Rockyg> ??
20:04:36 <bknudson> somebody posted on -infra that meet bot wasn't working.
20:04:36 <Rockyg> Oh.  Thanks bknudson
20:04:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:04:37 <Rockyg> 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 <openstack> The meeting name has been set to 'log_wg'
20:04:56 <jokke_> Rockyg: yeah never got the e-mail
20:04:59 <openstack> 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 <openstack> Minutes:        http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.html
20:05:02 <openstack> Minutes (text): http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.txt
20:05:04 <openstack> Log:            http://eavesdrop.openstack.org/meetings/log_wg/2015/log_wg.2015-04-08-20.04.log.html
20:05:05 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:05:10 <openstack> The meeting name has been set to 'log_wg'
20:05:12 <openstack> Rockyg: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
20:05:17 <Rockyg> A number of folks have gotten a rough draft of it.  I'll send to anyone who wants a copy
20:05:31 <Nikolay_St> Rockyg: send one to me :)
20:05:42 <Rockyg> Do I have your email?
20:05:47 <ekudryashova> To me too, please
20:06:05 <Rockyg> I thought I sent to jokke_ and ekudryashova already.
20:06:21 <jokke_> Rockyg: oh, darn ... yeah might be ... just PMing you
20:06:45 <jokke_> haven't been reading my personal mail box for few days
20:07:14 <Rockyg> anyway, I think it will dovetail with some discussion with the API proposal
20:07:32 <Nikolay_St> Rockyg: here it is nstarodubtsev dog mirantis.com
20:08:08 <Rockyg> Great.  Will send that out, shortly.  Any comments before I manage to get it into gerrit are very welcome.
20:09:05 <Rockyg> 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 <Rockyg> 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 <jokke_> no worries :D
20:12:43 <Rockyg> #topic API error code spec
20:12:45 <jokke_> send it out after
20:12:47 <Rockyg> Any thoughts?
20:12:51 <bknudson> Rockyg: were you planning to change the spec based on the current comments?
20:13:35 <jokke_> I don't like it but I seem to be pretty much the only one
20:13:47 <bknudson> don't like what?
20:14:08 <Rockyg> 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 <jokke_> the json dump on the api error proposal
20:14:59 <bknudson> jokke_: what would you prefer for an error response?
20:15:01 <Rockyg> 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 <bknudson> XML?
20:16:00 <Rockyg> 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 <jokke_> bknudson: I prefer error message, not hundreds of lines of json about every error that might have occured
20:16:40 <bknudson> I expect it will usually be a single error.
20:17:16 <bknudson> is the error message translated?
20:18:04 <ekudryashova> bkhudson: Yes
20:18:25 <jokke_> 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 <Rockyg> 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 <bknudson> 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 <bknudson> but the JSON error document doesn't seem like overkill to me... sure seems to have extra fields, though.
20:20:05 <jokke_> 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 <bknudson> e.g., status is redundant, and only one of id or code should be needed.
20:20:26 <Rockyg> 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 <bknudson> then all you have is id, title, description, and href, which seems like the right amount of info
20:21:27 <bknudson> where title and description are translated.
20:21:53 <Rockyg> 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 <bknudson> oh, I thought we were talking about the error response
20:22:24 <jokke_> so did I
20:22:43 <Rockyg> Ah. There's the rub.  Error response != log message
20:22:57 <jokke_> correct
20:23:16 <jokke_> but the error response spec was the one you asked thoughts for ;)
20:23:45 <Rockyg> Error response should be machine to machine.  But it often needs to propagate out to log
20:24:16 <bknudson> if it's machine to machine then translation isn't going to help
20:24:46 <jokke_> as long as it's machine2machine only thing that needs to be sent over is the error code
20:24:53 <Rockyg> bknudson: true, but some of the information propagated through to the log will need the translation
20:25:26 <bknudson> 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 <Rockyg> jokke_: error code plus payload -- instance info, request id, etc
20:25:47 <jokke_> bknudson: that's what I was expecting as well
20:25:53 <bknudson> and would hopefully tell me what to do to fix it.
20:26:15 <jokke_> IMO that is really just for the user
20:26:37 <Rockyg> Both:  right, but it's API info, so it's aimed at developer (at least this spec) rather than end user
20:26:37 <jokke_> but even then it wouldn't need title and description, we could just stick with the message
20:27:13 <bknudson> is description the message? what's the difference?
20:27:26 <jokke_> but yeah I do dislike tons of json and bundling multiple errors into single response
20:27:49 <Rockyg> Message is the payload.  It is the descriptive string with instance specifics included
20:28:36 <jokke_> 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 <Rockyg> I think now you guys are getting why I think there is lots of confusion around this and log stuff
20:29:21 <jokke_> Rockyg: I do agree ... because next thing is that pprojects starts dump that json into logfiles
20:29:29 <bknudson> 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 <Rockyg> 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 <bknudson> if we want a log guideline then we should say that nobody wants JSON dumps in their logs.
20:32:30 <jokke_> 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 <jokke_> bknudson: +++
20:32:42 <Rockyg> bknudson:  ++
20:33:59 <jokke_> 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 <Rockyg> 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 <Nikolay_St> jokke_: +
20:34:48 <jokke_> 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 <Rockyg> 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 <jokke_> :)
20:35:46 <jokke_> Rockyg: ++
20:35:59 <bknudson> Rockyg: don't worry about emailing me... get it in gerrit and I can look at it there.
20:36:04 <Rockyg> And, we can attend an APIwg meeting to further discuss
20:36:43 <jokke_> sounds like a plan
20:36:46 <Rockyg> 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 <Rockyg> #topic request IDs
20:38:08 <Rockyg> I'd like for folks to go over the #link https://review.openstack.org/#/c/156508/ and see what they think.
20:39:40 <Rockyg> 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 <jokke_> ok, so that's out there now
20:40:58 <Rockyg> jokke_:  ?? is out there?
20:42:19 <bknudson> wow... this is proposing change the responses from ... JSON to a tuple?
20:42:53 <jokke_> Rockyg: that spec on OS-specs finally
20:43:21 <Rockyg> Ah.  Yeah.  and it needs lots of comments.  and some visibility.
20:43:34 <Rockyg> Needs lots of work, I think.
20:43:49 <bknudson> there seems to be concerns about clients sending requests with the same request ID.
20:44:04 <bknudson> seems like if a client wants to screw itself then let them do it.
20:44:24 <Rockyg> <snicker>
20:45:41 <Rockyg> 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 <Rockyg> It's possible/likely that the approach gets tossed, but the concept is implemented differently.
20:47:02 <Rockyg> Perhaps just making the API WG aware of this and let them comment would be a good first step?
20:50:00 <Rockyg> Any further comments?  otherwise moving on...
20:50:23 <Rockyg> #topic summit
20:51:13 <Rockyg> I've suggested a general Ops session for log stuff.  What happened in Kilo, what to focus on in Liberty, etc.
20:51:41 <Rockyg> I'd also like to propose one for cross projects.  Will do that ASAP
20:53:06 <Rockyg> 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 <jokke_> sounds good to me
20:53:43 <bknudson> sounds good to me too
20:54:00 <Rockyg> 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 <Nikolay_St> and for me :) Sahara guys promise that they'll try to attend at least 1 meeting :)
20:54:47 <Nikolay_St> Rockyg: 1 hour earlier will be fine for me
20:55:15 <ekudryashova> +1 for earlier meeting
20:56:01 <Rockyg> Anyone here besides me and jokke_ going to be at the summit?
20:56:21 <bknudson> I plan to be at the summit... hasn't been totally confirmed yet.
20:57:48 <Rockyg> 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 <jokke_> cool
20:59:19 <Rockyg> 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 <Rockyg> #endmeeting