20:06:43 <jokke_> #startmeeting log-wg
20:06:43 <openstack> Meeting started Wed Mar 11 20:06:43 2015 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:06:47 <openstack> The meeting name has been set to 'log_wg'
20:07:02 <jokke_> so we have empty agenda and Rocky is also in the ops meetup
20:07:33 <Nikolay_St> guys, I miss the first meeting. what was it about? and what do we plan to discuss.
20:07:41 <jokke_> I promised to chair this in the case we have something that people wants to bring up. Otherwise we'll have really short one
20:07:55 <Nikolay_St> sorry for this question, it wasn't completely clear from mailing list
20:08:01 <jokke_> I did not actually check the agenda yesterday when I volunteered ;)
20:08:21 <Nikolay_St> :d
20:08:49 <nkrinner> so i think we had some action items from the last meeting. does anybody have something to report here?
20:09:14 <jokke_> Nikolay_St: http://eavesdrop.openstack.org/meetings/log_wg/2015/ there is the logs/minutes from last week
20:09:23 <nkrinner> i saw jokke_ wrote a mail to the devel mailing list, but with little response iirc
20:09:57 <jokke_> yeah did not seem to get that much attraction
20:10:30 <jokke_> Liaisons page has pretty much only people here listed ;)
20:10:43 <Nikolay_St> jokke_: thx, I miss it :)
20:11:11 <dhellmann> everyone is focused on finishing the work they need to do before the feature freeze next week
20:11:20 <dhellmann> jokke_: you may want to wait until the 23rd and send your email again
20:11:37 <jokke_> there was couple of other actions, but I doubt as usual no assignments nothing done
20:12:16 <jokke_> dhellmann: I was thinking that as well ... the timing might not be the best one for something that is bit abstract and does not have good surface for bikeshedding :P
20:12:43 <dhellmann> has anyone started making a list of the logging changes that we might want to make? for example, "when cinder does X it logs extra messages", or at the wrong level, or whatever
20:13:09 <dhellmann> jokke_: speaking of concrete actions ^^
20:13:18 <Nikolay_St> dhellmann: I have smthg like that in my mind about Sahara
20:13:55 <dhellmann> Nikolay_St: it would be good to pull notes about those sorts of things together into an etherpad so we can all add to it. Then we can either open bugs, or use the etherpad as a checklist as we make the relevant changes.
20:14:15 <Nikolay_St> dhellmann: ok, make sense
20:14:44 <Nikolay_St> dhellmann: I'm not focus on it right now, just some notices while implement 'correct logging'
20:15:04 <nkrinner> i have similar ideas about heat, but was unable to work on it as i am out of office busy with something else this week
20:15:22 <dhellmann> Nikolay_St: right, we don't have to build the whole list all at once, but if we share the list we can get ideas of what to look for in other projects and we will know what has already been noted
20:15:22 <Nikolay_St> btw, should I put a link to Sahara loggins spec here: https://wiki.openstack.org/wiki/LogWorkingGroup#Specs?
20:15:41 <dhellmann> telling the developers "fix logging" is not a useful request, but telling them, "here are 350 ways logging can be improved" is
20:16:03 <Nikolay_St> dhellmann: yeap, get it :)
20:16:14 <dhellmann> Nikolay_St: maybe you could take an action to create that etherpad to get us started?
20:16:16 <jokke_> should instruct naming format and add those etherpads to the wg wiki by the time someone brings such situations up as dhellmann referred above?
20:17:03 <Nikolay_St> dhellmann: no problem :)
20:17:04 <dhellmann> jokke_: it would give us something concrete for this group to be working on, too :-)
20:17:14 <Nikolay_St> jokke_: good idea
20:17:16 <jokke_> something like {project}-Logging-Improvements ... and listing those on one place ... I really would not like to see just one etherpad with all mixed together?
20:17:20 <dhellmann> #action Nikolay_St create an etherpad to hold notes about specific logging issues in applications
20:17:36 <dhellmann> Nikolay_St: thanks!
20:17:41 <jokke_> and if those etherpads are not listed, no-one will remember them ;P
20:17:56 <jokke_> gr8
20:17:58 <dhellmann> jokke_: let's start with one etherpad for now. We aren't going to be listing files and line numbers, just general notes
20:18:17 <dhellmann> as it grows, we'll see if we have to move to multiple pads or to bugs or something else
20:18:47 <jokke_> dhellmann: nope, I'm just afraid that those general notes becomes like the -dev mailing list just with a difference that you can't filter it :P
20:19:44 <Nikolay_St> dhellmann: multiple etherpads look good to me too
20:19:45 <dhellmann> jokke_: well, right now we just have a bunch of amorphous wishes to make things better, so let's start making a concrete list and see where that takes us
20:20:31 <jokke_> dhellmann: ++
20:21:06 <jokke_> dhellmann: it's always easier to make things better when people tells you what actually annoys them on current behavior
20:21:34 <dhellmann> jokke_: ++
20:22:13 <jokke_> #action jokke_ will try to pull more attention to the priority e-mail after 23rd of March
20:23:05 <jokke_> I'm not sure where this came last week "Identify guidelines that can make sense to add to Hacking" and I'm not sure this is really the right timing to spend time on something like that either
20:23:21 <jokke_> again action item that was not tagged to anyone
20:23:55 <dhellmann> it will be difficult to enforce these guidelines automatically, so I think we should focus on small concrete improvements before worrying about that
20:24:14 <Nikolay_St> dhellmann: +1
20:24:45 <jokke_> on X-project meeting yesterday there was mentioned that the request ID spec got new iteration but is apparently still under Cinder ... anyone has info about that?
20:24:53 <jokke_> dhellmann: exactly
20:25:14 <Nikolay_St> jokke_: not me
20:26:57 <dhellmann> jokke_: the filename still has "cinder" in it, irrc
20:27:36 <jokke_> dhellmann: was it actually on the openstack-specs repo or is it still in cider repo as well?
20:28:40 <dhellmann> jokke_: https://review.openstack.org/156508
20:28:45 <dhellmann> that's to the openstack-specs repo
20:30:38 <bknudson> what does the work item "Add support to check type of response returned by cinder-client in cross-projects" mean?
20:31:12 <bknudson> (wishes hacking could be smart enough to figure out if the logs were inadequate!!)
20:31:27 <bknudson> but then we'd all be out of work.
20:31:51 <jokke_> dhellmann: ok ... well that's good at least that it's there ... filename is easy fix to do ;)
20:32:43 <bknudson> btw - tokens from keystone now have an audit_id field, so this could be handy for tracking requests.
20:33:39 <dhellmann> bknudson: it would be useful to add that comment to the spec; I think we have 3 different groups trying to get request_ids into all requests now for tracking for different purposes.
20:33:54 <dhellmann> they all seem to be just part-time, though, so there's no real traction
20:34:18 <bknudson> if we could use the token audit_id along with a "key" configured in the request ID middleware we could have the request ID authenticated and not have to deal with it changing between services.
20:34:55 <dhellmann> bknudson: that sounds like a useful approach
20:35:39 <bknudson> dhellmann: are there x-project specs for other efforts?
20:36:05 <dhellmann> bknudson: no, those predate the xp specs repo
20:36:26 <dhellmann> the stacktach and rally folks both wanted this feature, iirc
20:39:57 <bknudson> trying to figure out the best way to move forward here... I feel like https://review.openstack.org/#/c/156508/ is way too limited, if it's only about cinder client.
20:45:13 <jokke_> bknudson: ++
20:52:44 <stevelle> that spec mentions a "larger effort to log request ID mappings across service boundaries" but do we have any spec on that yet?
20:53:12 <stevelle> is there a place we can reference the statement of purpose for this?
20:53:42 <jokke_> stevelle: that is the spec ... I think there is lots of work to do on that
20:54:11 <jokke_> so did we have something else for today before we run out of time or do we spend the last 5min around that?
20:54:29 <stevelle> jokke_: I was hoping that wasn't the answer we had, but I guess that means we get to ensure it is reviewed carefully
20:56:10 <jokke_> stevelle: yeah I think that spec needs to become 10 fold more specific before we even seriously start reviewing it ... those quotes are really good bad example it being just idea throw out without anything that could be tracked
20:57:57 <bknudson> if we're doing something for all clients then it should probably be in keystoneclient's session code.
20:58:54 <Nikolay_St> guys, time
20:59:10 <bknudson> maybe we'll have more energy next week.
20:59:30 <bknudson> busy times.
20:59:36 <jokke_> bknudson: I don't think that's right place either because then we limit it only on keystone enviroments
20:59:41 <jokke_> but thatks everyone!
20:59:47 <jokke_> thanks even
20:59:48 <bknudson> all clients use keystoneclient session
20:59:52 <bknudson> for auth
21:00:00 <jokke_> k
21:00:05 <stevelle> lets make sure to continue this next week on that
21:00:08 <jokke_> #endmeeting