15:01:06 #startmeeting nova-config-options 15:01:07 Meeting started Mon Jan 11 15:01:06 2016 UTC and is due to finish in 60 minutes. The chair is markus_z. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:10 The meeting name has been set to 'nova_config_options' 15:01:40 sfinucan: hey ho, let's see who got the short notice message 15:02:01 markus_z: uh, this is the zaqar meeting time/channel 15:02:12 I don't see nova-config on the os-meeting-cal 15:02:23 o/ 15:02:25 ryansb: I didn't see that in the ical 15:02:51 oh >.> don't mind me, I'm off by a week 15:03:08 carry on 15:03:33 ryansb: cool :) did I interrupt maybe another meeting, so speak up :) 15:03:59 no, doesn't seem like it (from the cal) sorry for the interruption 15:04:08 no worries 15:04:45 ah, well, let's just do it 15:04:50 #topic current state 15:05:09 so it's ccarmack and sfinucan 15:05:13 hi 15:05:24 hey ho 15:05:30 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/083598.html 15:05:45 I just wanted to have a short chat about the work on nova's config options 15:05:56 and again, thanks for your support their 15:06:24 do you maybe have some open questions until this point? 15:06:43 markus_z: I had a question about testing... 15:07:00 ccarmack: ok, go on 15:07:07 Do we need to write new tests if need to verify the options are not broken 15:07:29 I'm not sure the current tests exercise all the options 15:07:47 ccarmack: I'd say "no". 15:08:10 Are you worried that they don't get read? 15:08:42 I'm more worried about breaking on option, like changing the name or the default 15:09:21 I guess careful inspection is what we can do 15:09:24 the name change should already be catched by unit tests 15:10:04 ccarmack: If you don't actually change the default or name you should be fine, right? 15:10:26 I mean, you could but a code reviewer _should_ pick it up 15:10:28 sfinucan: yes, just need to be careful 15:10:54 I will have a look at that in the reviews 15:11:00 ok 15:11:04 ccarmack: True. I've kept changes related to renamed groups etc. in different commits 15:11:17 I don't think we need additional testing here. 15:11:33 renaming groups is a different thing. That needs deprecation and reno files 15:12:06 Did that already happen and I overlooked it? 15:12:23 markus_z: Not from me, no 15:12:41 I have some in review sans reno, but I'll go fix that soon :) 15:12:54 ok, cool 15:13:05 markus_z: I have a question, so? 15:13:11 sfinucan: sure 15:13:35 Is there anyway to go about getting these merged faster? 15:14:06 This review should be the last one which helps us with the merge conflicts https://review.openstack.org/#/c/260015 15:14:22 That should speed things up 15:14:30 I guess I'm the bottleneck right now 15:14:39 As long as I don't +1 it the cores won't look at it 15:15:08 markus_z: Ah - I saw that but didn't know how critical it was. I'll rebase my changes onto it 15:15:13 ...or wait for it to merge 15:15:33 sfinucan: yeah, wait for the merge. I'm fighting with XENCI right now. Should be done by today. 15:15:54 OK. Even once that bottleneck's cleared though, I'm finding it hard to get eyes on. None of us are cores so we can't force things :( 15:15:59 It also helps if you already have the enhanced help texts in a followup patch 15:16:11 markus_z: Oh yeah? 15:16:33 I was figuring they'd be more contentious, so was focusing on the easier, even-lower-hanging fruit first :) 15:16:46 yeah, that's the main focus of this task 15:17:11 It should be somehow a single bucket to look at 15:17:36 This is true 15:17:51 OK, I'll put some energy into that later today/tomorrow so 15:17:52 mitaka-2 milestone is ahead any many people try to merge their features, that's also why the cores have less time 15:18:11 markus_z: also true (I'm one of those people) 15:18:30 markus_z: One more question? 15:18:46 How broad reaching is this spec going to be? 15:18:46 I have to discuss with our PTL if we will be concerned by the cut-off date or if we can keep on pushing changes as we don't provide a feature which could introduce major bugs 15:18:58 what do you mean by that? 15:19:15 Are we going to be concerning ourselves with those "items for consideration"? 15:19:41 i.e. "this patch is a stringopt when it should be an integeropt" 15:19:41 hm, what are "items of consideration"? Did I miss something? 15:19:50 ah, ok, got it 15:20:05 just note it down for later 15:20:15 the main focus is help text for our opts 15:20:21 sfinucan: for the help text, I see you committed the vnc changes. I did the spice changes, but have different help text. https://review.openstack.org/#/c/264271/ 15:20:23 good help texts for our opts 15:20:43 we should have simliar text for the console groups 15:21:07 sounds reasonable, but don't let the perfect be the enemy of the good 15:21:08 ccarmack: Agreed. I copied mine from somewhere else, though I don't recall where... 15:21:39 I'm happy to fix - feel free to stick in 'nit:' comments as suits, ccarmack 15:21:49 sfinucan: maybe when are changes are reviewed, we can match up the help text 15:21:52 ok, will do 15:22:59 ok, cool, more questions? 15:23:25 ccarmack: Maybe stick in the "preferred" format in the spec - I'll copy that 15:23:34 markus_z: Not from me, no 15:23:47 markus_z: I'm good 15:24:25 ok, I'd like to give you a heads up for this patch: https://review.openstack.org/#/c/260015/4 15:24:39 It introduces a change for your /nova/conf/xxx.py modules 15:25:32 In the previous patches you returned a tuple in "list_opts", like return ("vnc", vnc_opts) 15:26:00 that will change to a dict like return { "vnc": vnc_opts } 15:26:35 the new "nova/conf/opts.py" module will then read it in and everything is fine 15:26:41 markus_z: Sounds good. I'd suggest also putting that into the spec 15:26:56 you just have to remove a previous reference in the old "nova/opts.py" (or similar) 15:27:38 sfinucan: yeah, a follow up patch there makes sense, it's a somewhat bigger change in that concept 15:28:44 the change also means that all the spread "opts.py" modules will be stripped down with the listing of the config options until they don't have any listing anymore 15:29:02 because everything is done automatically by the one and only "nova/conf/opts.py" 15:29:13 all other opts.py modules will be deleted at the end 15:29:24 does that make sense to you? 15:30:17 #link example of stripping down an opts.py module: https://review.openstack.org/#/c/260015/4/nova/opts.py 15:31:47 markus_z: Yes, I think so 15:31:51 If not, I'll ping you :) 15:32:13 :) yepp, please do so 15:32:39 ok, that are the major points I wanted to discuss 15:32:54 Thanks again for helping with that 15:33:06 Any open questions? 15:33:12 none from me 15:33:58 cool, thanks for your participation :) 15:34:00 #endmeeting