21:15:17 <rockyg> #startmeeting log_wg 21:15:18 <openstack> Meeting started Wed Jan 13 21:15:17 2016 UTC and is due to finish in 60 minutes. The chair is rockyg. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:15:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:15:22 <openstack> The meeting name has been set to 'log_wg' 21:15:50 <rockyg> #topic Open Discussion 21:15:53 <rbradfor> o/ 21:16:01 <rockyg> dhellmann, do you have something? 21:16:19 <rockyg> or rbradfor ? 21:16:28 <SamYaple> o/ 21:16:36 <dhellmann> rockyg : nothing new, just finally making it to the meeting again to catch up :-) 21:16:36 <rbradfor> I have some updates. 21:16:43 <rockyg> Oooh! SamYaple , too. 21:17:05 <rockyg> So, glad dhellmann could make it as I'd like to fly something by you. 21:17:16 <rockyg> But lets start with updates! 21:17:31 <rockyg> #topic Update from rbradfor 21:17:37 <rbradfor> I've got several documented examples for various oslo projects, starting with oslo.log and https://review.openstack.org/#/c/264977/ 21:17:57 <rbradfor> #link http://docs.openstack.org/developer/oslo.log/usage.html 21:18:30 <rbradfor> I'm working on next iteration that provides Context examples and usage, and then varying format strings valid parameters. 21:19:06 <rbradfor> I also have several patches for deprecated logging options, to get them removed, and unclutter the docs a bit. 21:19:41 <rbradfor> and just submitted a patch to correctly generated deprecated documentation of options, https://review.openstack.org/#/c/267151/ 21:19:47 <rockyg> Excellent! 21:20:12 <rockyg> Apps developers will be so happy 21:20:21 <rbradfor> I will be proposing via ML later suggestions for identifying a what to better document what release option is deprecated and when it is to be removed. I have a high road nad low road 21:21:05 <rbradfor> this is just some ground work for providing better information to devs and ops on logging capabilites. 21:21:29 <rockyg> make sure you include the ops ML when you post 21:22:11 <rbradfor> this first email will be about how developers should identify this information. 21:22:19 <rockyg> Any questions/comments for rbradfor? 21:22:26 <rbradfor> how that is then presented will be of benefit to the operators 21:22:47 <rbradfor> one more thing. 21:23:03 <rbradfor> #link https://review.openstack.org/#/c/263468/ 21:23:59 <rbradfor> this has now greatly simplified how projects extend the default logging levels on startup, as in the now produced docs. This will help to remove confusion and duplication, bringing an future oslo.log changes available to projects that implement this new method 21:24:10 <rockyg> #link https://review.openstack.org/#/c/264977/ 21:24:24 <rockyg> #link http://docs.openstack.org/developer/oslo.log/usage.html 21:24:37 <rockyg> #link https://review.openstack.org/#/c/267151/ 21:24:55 <rockyg> #link https://review.openstack.org/#/c/263468/ 21:26:13 <rockyg> excellent! This actually dovetails into what I think the next topic is and bringing dhellmann into the discussion 21:26:24 <rockyg> OK to move to next topic? 21:26:38 <rbradfor> yep! 21:27:19 <rockyg> #topic Config options -- prerequisite for sane logging 21:27:49 <rockyg> rbradfor and I have been discussing the state of config options 21:28:46 <rockyg> We realize that it will be hard to get log levels in good shape if we don't have consistency in the configuration (among other issues, but this is a biggie) 21:29:54 <rockyg> We both (and many Ops guys) see the lack of a good, documented way of providing global opts with local overides a major shortcoming to OpenStack. 21:30:16 <rockyg> but first, before we can do much here, we need to document the current state 21:30:49 <rockyg> So, this sounds a little off topic for logging, but it's important for logging. 21:31:49 <rockyg> I want to throw together a spreadsheet that documents all the config options, what their defaults are, where the opts are defined and where they are set/reset, an values 21:32:01 <rockyg> Starting with the core six projects. 21:32:41 <rockyg> Then open the spreadsheet up for edits to get it better representative of what's really out there. 21:33:32 <rockyg> From there, discussion can arise on whether the values are right, whether individual projects should change/remove/add opts in their config files, etc. 21:34:00 <dhellmann> what do you mean by "global opts with local overrides"? 21:34:26 <rbradfor> rockyg, I feel that running oslo-config-generator for the projects, and then perhaps aggregating this via some simple scripting will provide the "all the config options" 21:34:48 <rockyg> actually, all of them. The project specific ones and the global. The table/spreadsheet would have the global first, but then also have the project specific 21:35:14 <dhellmann> I don't know what a "global" option is, though. Do you mean an option that applies to all projects? 21:35:18 <rockyg> rbradfor, that was one of my next questions! 21:35:57 <rockyg> "global" is pretty much the olso config opts. They have defaults, but also get set in lots of projects 21:36:06 <dhellmann> ok 21:36:36 <rockyg> And you're right, we all agree that there aren't "global" config opts as yet. Oslo is as close as it gets 21:37:12 <rbradfor> so perhaps a suggestion is find common options 21:37:29 <rbradfor> that later may be a candidate for a possible global conf file 21:37:47 <rbradfor> and definitely for a global docs section on common options 21:37:52 <rockyg> I'm thinking that until we have something that documents the current state, we really can't do a good analysis to see if there are any improvements we can make or what the impacts would be 21:38:26 <rbradfor> rockyg, is your first goal to simplify docs? 21:38:44 <rockyg> And getting these (all of them) documented for ops/enduser docs for Mitaka would be something we think worthwhile 21:39:47 <rockyg> First goal is to get the current state documented and in such a way as the docs folks can propagate this infor in the current docs. What you said, plus letting devs and community know what's what 21:39:56 <dhellmann> we added code to oslo.config to integrate with the documentation build for projects last cycle. that same code can be used to generate a document describing all of the options by running it against all of the projects instead of just one project. 21:40:52 <rockyg> Fantastic! I bet the docs folks will be happy. It also means that oslo *can* have a separate section in the config doc. 21:41:19 <dhellmann> http://docs.openstack.org/developer/oslo.log/opts.html 21:41:24 <dhellmann> that's an example of the output for oslo.log 21:41:39 <rockyg> Once we have all this, ops folks and others can see if the values make sense and file bugs on ones that don't. 21:41:52 <rockyg> This also may help the nova config opts effort. 21:42:04 <dhellmann> is there a separate config guide? 21:42:08 <dhellmann> or is that part of the install guide? 21:42:22 <rockyg> there is a separate config guide 21:42:49 <dhellmann> found it in http://docs.openstack.org/liberty/config-reference/content/ 21:42:55 <rockyg> It currently has no oslo section, just projects that have multiple sections on how to config various things 21:43:00 <dhellmann> it looks like they're still using docbook for that, so we'll have to wait for the migration to sphinx 21:43:18 <rbradfor> rockyg, one thing you mentioned as a concern was "what are new options" or "changed values of options" in the next release. I guess you want this in this doc too. 21:44:01 <rockyg> Yeah. 21:44:49 <rockyg> and that goes towards the discussion of ReNo and DocImpact that is happening now. 21:45:25 <rockyg> Hopefully all config add/change/remove will get ReNo. 21:45:37 <rockyg> But the docs folks also have to incorporate. 21:46:10 <rbradfor> I feel we need to get the docs folks to start with exsting docs and having a "common" or "Oslo" options section 21:46:25 <rbradfor> simply reducing the documentation is an effective benefit for operators. 21:46:47 <rockyg> Yup. I started that discussion with Lana and Anne at the summit. Lana is up for it and explained why to Anne. 21:46:56 <rbradfor> can what you propose in this config guide be incoporated into already existing and known documentation people at least use and my be familar with 21:47:45 <rockyg> I think ops are familiar with the config ref. They need to be if they want to change any values. Which lots of them do. 21:48:48 <rockyg> dhellmann, do you think this is a reasonable prerequisite for getting options more consistent across a deployment, along with providing a base for identifying misleveled log messages? 21:49:59 <rockyg> Also, we can bring Ops and UC folks into the discussion once we have generated the pieces of docs 21:50:05 <dhellmann> there will need to be an updated config reference for mitaka, so getting that into good shape seems like a good place to start 21:50:42 <dhellmann> we should look into how that guide is built now, and whether the doc team has it on their sphinx conversion plan already 21:51:00 <rockyg> Great! 21:51:03 <dhellmann> and then start contributing to it to update it 21:51:21 <dhellmann> like rbradfor said, having a completely new guide is likely to confuse folks as much as anything 21:51:30 <rockyg> #action configuration reference doc discussion with docs team 21:52:04 <rockyg> A concatenated list of options could always be added as an adendum this round. 21:53:40 <rockyg> OK. rbradfor could you generate the doc files from the configs you are aware of? I'll go searching to see if there are strays elsewhere and also discuss this with the nova config opts lead? 21:54:51 <rbradfor> rockyg, are you seeking a http://docs.openstack.org/developer/oslo.log/opts.html format of options for projects, rather then a sample.conf file? 21:55:44 <rockyg> I will also go through and find dupes/changed values/etc once we have the list. Good place to start the discussions. And a good way to make devs aware of the oslo opts. And, yeah. If we can get the html format for the core six projeccts, that would be great. 21:56:20 <dhellmann> rockyg : my comment about generating that documentation for all projects in one guide depends on a tool change by the docs team 21:56:26 <rockyg> Nova, cinder, Neutron, Keystone, Glance, Swift Am I missing any? 21:56:28 <dhellmann> that's why I brought up the sphinx conversion plan 21:56:44 <rbradfor> dhellmann, whats the sphinx conversion plan? 21:56:57 <dhellmann> rbradfor : the docs team is converting from docbook to sphinx, one manual at a time 21:57:05 <dhellmann> I don't know what the schedule is, or the order. 21:57:32 <rockyg> Right. I'm not yet read for the docs, but if we can get the html files, that will let us do some analysis while we talk to docteam 21:57:39 <dhellmann> the thing we're using in oslo.log to generate that table depends on being integrated into sphinx, not the docbook tool chain they are using now 21:57:48 <rockyg> not yet ready... 21:58:14 <dhellmann> as an interim measure we could add a similar page to all of the individual projects in their developer documentation 21:58:29 <rockyg> So, nova uses sphinx for a bunch of their stuff. Is that enough, or are there specific things? 21:58:51 <dhellmann> some folks have started doing that, and are keeping notes in https://etherpad.openstack.org/p/automating-oslo-config-documentation 21:59:00 <rockyg> dhellmann, ++ That gives *us* what we need to start. 21:59:10 <dhellmann> rockyg : someone needs to add instructions to the nova docs that say "put the configuration options here" 21:59:14 <rockyg> #link https://etherpad.openstack.org/p/automating-oslo-config-documentation 21:59:47 <rockyg> I expect that is what is needed for each of the projects? 22:00:27 <dhellmann> right 22:00:42 <rockyg> You just need someone to go down the list and hit every project? I can certainly work on that. 22:00:50 <dhellmann> yep 22:01:01 <rockyg> kewl. 22:01:15 <rbradfor> dhellmann, of those projects in the etherpad, docs.o.o/developer/project are already sphinx generated 22:01:25 <dhellmann> yes, they should be 22:01:45 <dhellmann> so for these cases we just need to add the page containing the directive from oslo.config to spit out the options 22:01:50 <rockyg> So, it's just adding the directive/matching the example. 22:02:42 <rockyg> OK. I think rbradfor and I have our work cut out for us. And we are past time. 22:02:46 <rockyg> We all good? 22:02:47 <rbradfor> rockyg, I can take a look at this for one project to see what the output comes out like. is nova (biggest and hardest) the place to start 22:03:50 <rockyg> Yup and the team working on making the opts better has an etherpad with team member names and stuff here: #link https://etherpad.openstack.org/p/config-options 22:04:09 <rockyg> Yay! I'm calling it. 22:04:19 <rockyg> Thanks all and dhellmann 22:04:27 <rockyg> #endmeeting