20:02:00 <Rockyg> #startmeeting Log_wg
20:02:01 <openstack> Meeting started Wed Mar 18 20:02:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:05 <openstack> The meeting name has been set to 'log_wg'
20:02:14 <Nikolay_St> ok, nice
20:02:31 <Rockyg> Welcome, folks
20:02:46 <bknudson> hi
20:02:52 <Nikolay_St> o/
20:04:11 <Rockyg> Agenda got updated on the wiki page
20:04:19 <bknudson> link?
20:04:41 <Rockyg> #link https://wiki.openstack.org/wiki/Meetings/log-wg
20:05:29 <Rockyg> #Topic Liasons -- intros and updates
20:06:05 <Nikolay_St> nothing from my side on this topic
20:06:27 <bknudson> I'm going to add asking someone to sign up as keystone liaison to the keystone meeting next week.
20:06:35 <bknudson> if nobody else signs up it'll be me.
20:06:51 <bknudson> (it'll be me)
20:07:06 <Rockyg> #action bknudson will try to get someone as Keystone Liaison
20:07:46 <Rockyg> johnthetubaguy is Nova, but has a scheduling conflict for the meetings
20:08:39 <Rockyg> I have an action item from the first meeting to try and get signups.
20:09:10 <Rockyg> Should we try for an Ops liaison, too?
20:10:21 <Rockyg> Sounds like we are ready for next topic
20:10:23 <Nikolay_St> Rockyg: what do you meand under Ops?
20:10:32 <Nikolay_St> *mean
20:10:38 * bknudson added topic to keystone meeting agenda.
20:11:10 <Rockyg> Nikolay_St:  Yes.  Someone to monitor and get Ops participation when needed
20:12:17 <Rockyg> Let's move to next  topic
20:12:25 <Rockyg> #topic review of action items
20:13:21 <Rockyg> I'll start with mine from 3/4....Error code spec
20:14:16 <bknudson> is there a spec?
20:14:16 <Rockyg> It's within an hour of first draft submit to gerrit but I got a new laptop last fall and have to reinstall the apps to be able to do the git review from it
20:14:50 <Rockyg> Working through the process now, so should be able to submit either today or tomorrow
20:14:50 * bknudson isn't sure why error code spec is in logging working group?
20:15:08 <bknudson> thought it would be api
20:15:26 <Rockyg> Overall spec for error codes.  Error codes can be used for non-api stuff, too.
20:15:44 <Rockyg> Every error message should have an identifying code.
20:16:01 <bknudson> ahh. we've got a system here that tags them in the po file.
20:16:17 <Rockyg> po?
20:16:22 <bknudson> the messages file
20:16:44 <Rockyg> Ah.
20:17:06 <bknudson> I don't know how well it works of if it's really used.
20:17:41 <Rockyg> also, since they *should* be part of message header, they  get implemented in oslo.log as part of the message formatting
20:17:44 <bknudson> essentially generates an ID from the message text, or you can override it with a specific ID.
20:18:35 <Rockyg> Can you put up a link to either that code or better a spec or blueprint?  It would be good to read up on it
20:18:51 <Rockyg> also, I don't think every project has that
20:19:16 <bknudson> no project has it, it's in our product... so we don't have a spec or blueprint... although maybe we did think about upstreaming it at some point.
20:19:37 <bknudson> will ask around.
20:19:48 <Rockyg> Cool.  It might end up useful as part of this effort
20:20:24 <Nikolay_St> I agree with Rockyg
20:21:21 <Rockyg> jokke_  dhellmann and I had discussed a tool that would assign the number part of the error code and in the process, would take the description and put all in a database.  so we don't have duplicate codes and we always get a description
20:22:11 * bknudson is looking at the code now... (internal only)
20:22:43 <Rockyg> anyway, I'll post a message to the dev and ops mailing lists when I get the first rev into gerrit.  And everyone can review it
20:23:01 <Nikolay_St> Rockyg: sounds good
20:24:01 <Rockyg> Second AI I had was getting a cross project owner for the referrer ID spec.  It appeasrs that also got discussed last meeting.  can we get links to all the project specific specs posted here?
20:24:38 <Rockyg> johnthetyubaguy wants to do some work in this area and I thought he might be a good owner for the xproject spec
20:25:00 <bknudson> y, this tool that we have isn't really appropriate for how openstack does things. Packagers like us can use it.
20:25:11 <Nikolay_St> #link http://specs.openstack.org/openstack/sahara-specs/specs/kilo/sahara-log-guidelines.html
20:25:17 <bknudson> but, maybe it provides some ideas for how to do it in os.
20:26:27 <Rockyg> bknudson, that would be cool.  FYI the error codes on everything go back to mainframe and high performance compute vendors.  books of error codes and what they meant
20:26:50 <bknudson> y, that's why we did it... we're old hands at this.
20:27:20 <Rockyg> Also cool.
20:28:40 <Rockyg> We've got the link to the Sahara spec.  I think there's a cinder spec also.  I'll see what I can find on that one and add it to the LogworkingGroup page
20:29:07 <Nikolay_St> Rockyg: Sahara spec is on the page, also
20:29:22 <Rockyg> Yup.  Saw that.  Thanks!
20:30:00 <Nikolay_St> I think we can go with my item from 3/11
20:30:08 <Nikolay_St> the etherpad is here
20:30:21 <Nikolay_St> #link https://etherpad.openstack.org/p/Logging-Improvements
20:30:27 <Rockyg> typed faster than me;-)  Thanks
20:30:46 * bknudson is looking forward to spec on message ids... will add folks here who are interested.
20:31:43 <Nikolay_St> as I said on previous meeting I still don't have enough time to contribute some *big* things for improvement
20:31:54 <Nikolay_St> just some notices after logs refactoring
20:32:34 <Nikolay_St> I hope that other Sahara guys who is involved in logging improvement logging could contribute before next meeting of LWG
20:32:52 <Nikolay_St> or I will contribute after I discuss some questions with them
20:32:59 <Rockyg> That's good stuff, though, and reviewing the xproject specs, or getting some project eyes on them will go a long way
20:34:15 <Rockyg> nikolay_St: is Sahara tagging log bugs?  If not, could you create a log tag ans start?
20:35:06 <Nikolay_St> Rockyg: uhm... looks like I can't get the point :(
20:35:31 <Nikolay_St> Rockyg: I'm sure that we don't tag log bugs
20:35:44 <Nikolay_St> Rockyg: but can't get what you want me to do
20:35:53 <Rockyg> In launchpad, bugs filed against Sahara have tags.  If you know of bugs related to logging, just add the tag "log"
20:36:58 <Rockyg> Also, in the ehterpad you posted, Item 2, are bugs filed for either of the examples?
20:38:01 <Rockyg> And, is Sahara using oslo.log?
20:38:10 <jokke_> ,wi25
20:38:22 <jokke_> sorry
20:38:47 <Nikolay_St> Rockyg: yeap, Sahara using oslo.log
20:39:18 <Nikolay_St> Rockyg: not yeat, have no time for this :( was busy with devstack artifacts
20:39:39 <Nikolay_St> Rockyg: will be back for logging before the end of the week
20:40:27 <Rockyg> That's OK.  But we need to get them filed soon after 3/23 so that Oslo can fix as many as possible so Sahara (and other projects') code can work properly
20:42:17 <Rockyg> Also, FYI for people interested in this stuff, Oslo has (or will have) a config option inglobal requirements text file to set logging to syslog format.  All projects using oslo.log will get the benefit of consistency
20:42:43 <Nikolay_St> Rockyg: it's not the *bug* related for oslo.log
20:42:58 <bknudson> I'm not sure whether the default oslo.log config is all that useful for real deployments...
20:42:58 <Nikolay_St> Rockyg: finally I get what you're talking about :)
20:43:06 <bknudson> they probably need to use a logging.conf file
20:43:34 <Rockyg> bknudson:  good to know.
20:43:35 <bknudson> #link https://review.openstack.org/#/c/164851/
20:44:22 <bknudson> oslo.log is handy for the default config that we run in the gate and during dev, but real deployments are probably going to want a file/syslog rather than stdout.
20:44:49 <bknudson> The above link is an oslo.log spec that folks here might be interested in (add yourself)
20:44:57 <Rockyg> doh.  Yeah!
20:45:43 <Rockyg> One of the aims with this group is at a minimum to get a decent syslog compliant config
20:46:04 <bknudson> I like that idea... would make oslo.log useful.
20:46:12 <bknudson> more useful (sorry0
20:47:02 <Rockyg> dhellmann and team says oslo.log is already set up to do that, it's a matter of setting up the config.
20:47:22 <Rockyg> also, logging different levels to different files and dynamic changes to that
20:47:26 <bknudson> if it was just a switch --use-syslog or use_syslog=True that would be nice.
20:47:46 <bknudson> and also if it was tested in devstack would be bonus.
20:47:56 <Rockyg> That's what it is supposed to be.
20:47:58 <bknudson> tested in gate.
20:48:19 <bknudson> (if this is how we expect real deployments to operate)
20:48:38 <Rockyg> Write all these things down in the etherpad.  we can make specs or blueprints for them if they aren't in the code, and then they can be prioritized.
20:49:05 <bknudson> y, we already have this option in keystone: http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n165
20:49:09 <bknudson> have not tried it.
20:49:21 <Rockyg> OK.  Let's get an update on jokke_ 's action item.
20:50:07 <bknudson> do we have an etherpad for these things already?
20:50:20 <Rockyg> Yes.  That's the same option that dhellmann wants to have in global so that everyone who uses oslo.log will automatically get syslog on the projects' errors
20:50:20 <jokke_> No update ... will get chaser out there next week when we have got over this freeze panic across the border
20:50:29 <jokke_> s
20:50:48 <Rockyg> #link https://etherpad.openstack.org/p/Logging-Improvements
20:51:05 <bknudson> oh, thought that was just for sahara.
20:51:16 <Nikolay_St> bknudson: nope
20:51:43 <Rockyg> I think it's more important to categorize the issues and improvements by log area than by project area.
20:52:06 <Nikolay_St> bknudson: it was create as a place to collect an information about all possibilities and projects
20:52:17 <Rockyg> But, we also have another etherpad for general notes.  Wait a sec...
20:53:03 <Rockyg> #link https://etherpad.openstack.org/p/Log-Working-Group
20:53:26 <Rockyg> That might be a good place to put xproject improvements
20:54:30 <bknudson> where do you want syslog logging?
20:55:14 <bknudson> it's easy enough to move, so I'm not worried about it (bikeshedding)
20:55:24 <Rockyg> I think logging improvements is the place.  We can link to that etherpad from the WG one
20:55:51 <bknudson> ok
20:57:09 <Rockyg> Let's move on
20:57:21 <Rockyg> #topic relevant specs
20:57:49 <bknudson> oops, should have waited.
20:57:50 <bknudson> #link https://review.openstack.org/#/c/164851/
20:58:13 <Rockyg> We'll need to get as many of the project specific specs idenified as possible, including Oslo ;-)
20:58:20 <Rockyg> Thnaks bknudson
20:58:49 <bknudson> If I was making changes in keystone to improve logging I'd just file bugs or just post the change.
20:58:55 <Rockyg> We should add those to either etherpad or wiki.  I'm thinking wiki.  we've got a spot for that on the wiki page already
20:59:28 <Rockyg> When you file the bug(s) tag them with "log"
20:59:42 <Rockyg> That way we'll have a way to select for them across projects
21:00:28 <bknudson> find this one? https://bugs.launchpad.net/keystone/+bug/1432191
21:00:29 <openstack> Launchpad bug 1432191 in Keystone "Logs useless debugging issue with external auth" [Low,In progress] - Assigned to Brant Knudson (blk-u)
21:01:37 <Rockyg> This is the kind of info the liaisons need to spread through project meetings
21:01:51 <Rockyg> Ooooh! look at that! a bug with a log tag!
21:02:04 <bknudson> there's 2 now.
21:03:11 <jokke_> :)
21:03:40 <bknudson> the link to log bugs is too long, so just put it in the etherpad.
21:04:19 <Rockyg> I think I need to add the tag to the OpenStack over project
21:06:23 <Rockyg> but if you do an advanced search, a fuel bug and a keystone bug turn up
21:07:13 <Rockyg> Thanks for the link.  Yeah, I'm hoping with tags, we can make the dashboard query a lot shorter.
21:08:07 <Rockyg> Oops.  I think we ran over.
21:08:13 <Rockyg> #endmeeting