16:07:32 #startmeeting oslo 16:07:33 Meeting started Fri Oct 24 16:07:32 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:07:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:07:36 The meeting name has been set to 'oslo' 16:07:43 sorry for starting a bit late! 16:07:46 who else is here? 16:07:47 o/ 16:07:49 o/ 16:07:51 yo 16:07:54 o/ 16:07:56 My calendar failed to remind me too. 16:08:04 Guess it's Friday for everyone. :-) 16:08:19 hi 16:08:21 #action dhellmann send an email reminder of the time change before our next meeting 16:08:22 o/ 16:08:38 o/ 16:08:50 we don't have a lot to go over this week 16:08:57 did everyone have a chance to review the summit schedule? 16:09:08 o/ 16:09:12 link? 16:09:22 #link http://kilodesignsummit.sched.org/overview/type/oslo#.VEp5rr5hUts 16:10:06 what's reqd for liasons? 16:10:09 I tried to avoid known conflicts, but as usually we can only do so much 16:10:30 bknudson: we'd like you to be there for the wed 11:00 session "oslo graduation schedule" for sure 16:10:40 other than that one, I think it's safe for you to pick based on interest 16:11:02 y, and lack of conflict with our own proj schedule 16:11:27 the thurs 17:20 session "moving oslo away from namespace packages" will have an impact, but we'll be making the migration plan clear so it's safe to miss that one 16:12:01 bknudson: right. If there's something you especially want to be present for, I can try to juggle, but our options are pretty limited (I have at least 3 sessions I can't move because of other known conflicts) 16:12:44 I'll just have 4 or 5 etherpads open 16:12:47 between now and the summit, we should review the existing specs because I anticipate having quite a few more after the summit 16:13:14 #link https://review.openstack.org/#/q/project:openstack%2Foslo-specs+is:open,n,z 16:13:54 does anyone have any red flags to raise this week? 16:14:52 nopers 16:14:56 Are we going to require the lib name prefix on specs you and ttx were discussing earlier? 16:15:15 oh, bknudson, the proposed session on encrypting/obscuring config files didn't make the cut in part because of lack of info -- do you and morganfainberg have a spec planned? 16:15:21 not really a red flag but keystone is held back in the switch to oslo.config. 16:15:37 dhellmann: I hope to have time to put together a spec. 16:15:45 bknudson: what's holding you up? the config generator? 16:15:56 dhellmann: y, switching to the config generator 16:16:03 actually, that's holding Heat up too 16:16:19 I wasn't sure how to migrate the generate_sample script 16:16:20 there are reviews / bugs for the issues... I think there's a review for missing opts in oslo-incubator 16:16:27 Are there examples of how to handle that? 16:16:42 and then there's the bug I wrote up for the order of options in the generated file. 16:16:56 bknudson: I think https://review.openstack.org/#/c/113940/ should fix that, right? 16:16:57 shardy: let me point you to dolphs work in keystone. 16:17:04 bknudson: thanks! 16:17:12 dhellmann: yes, https://review.openstack.org/#/c/113940/ is needed 16:17:25 ok, cores, let's see if we can review ^^ today or monday 16:17:34 ack 16:17:44 oh, hrm, that's blocked on the patch for removing the log module 16:17:45 shardy: https://review.openstack.org/#/c/113905/ is the keystone work to switch 16:17:59 I should rebase that and add the logging options back to it 16:18:10 The bug is https://bugs.launchpad.net/oslo.config/+bug/1356591 -- "oslo-config-generator alphabetizes options" 16:18:12 Launchpad bug 1356591 in oslo.config "oslo-config-generator alphabetizes options" [Medium,Triaged] 16:18:28 but I can live without the bug fix since we're early in K. 16:18:35 bknudson: most helpful, thanks :) 16:19:44 bknudson: yeah, I think we could just emit the options in the order they are registered to give projects control over that 16:20:14 beekneemech: good question about the spec prefix, I wanted to ask the group before proposing that we do it. Thoughts? 16:20:31 dhellmann: Seems like a good idea to me. 16:21:57 I don't know if everyone knows what we're talking about though. :-) 16:22:17 beekneemech: oh, good point 16:22:32 Basically the suggestion was to keep the single oslo-specs repo, but require that lib-specific changes have their title prefixed with the name of the lib. 16:22:59 we already include the name of the lib in the spec, but this would make it easier to scan the list of reviews 16:23:08 Yep 16:23:43 we can go through gerrit and update the existing copies, but if someone submits an update they would have to preserve that change 16:24:23 Yeah, I'm sure it will get missed a few times, but it's a start. 16:24:48 how about if we give it a try and see if it makes reviews easier or harder 16:25:01 can I get a volunteer to update the existing reviews through the gerrit UI? 16:25:01 wfm 16:25:32 I can do that. There aren't too many open right now. 16:25:37 beekneemech: thanks 16:25:48 #action beekneemech add lib name prefixes to titles for existing specs 16:26:13 we should also make sure that each spec refers to its blueprint 16:26:36 I see a few that don't have the topic set, so I think that means they don't refer to the bp in their commit message 16:27:01 Hmm, yeah 16:27:35 o/ sorry for the delay 16:27:48 hi, dimsum_. no worries, we started a little late. 16:28:30 I don't see any specs ready to be approved, yet, but some seem like they're close. I'll check Monday to see where things stand after we've had a chance to review more. 16:28:59 are other people going to be travelling next friday? I was considering cancelling the meeting, since it's right before the summit 16:29:56 I'm not, but that doesn't seem like the most productive meeting time either. 16:30:01 yeah 16:30:23 does anyone object to cancelling the meeting on oct 31? 16:30:29 Probably better if everyone spends the time brushing up on the summit topics. 16:30:36 * dhellmann nods 16:30:45 +1 to no meeting 16:30:48 +1 to cancel 16:31:10 +1 16:31:27 +1 16:31:39 ok, liaisons we'll still (mostly) be on IRC so hit us up informally if you run into issues 16:31:48 #info no IRC meeting on Oct 31 16:32:04 Maybe I'll go trick-or-treating instead ;-) 16:32:10 yay 16:32:17 #info next IRC meeting 17 Nov 16:00 UTC in #openstack-meeting-alt 16:32:34 beekneemech: haha 16:32:51 ok, big question: who is going to be able to make it to the summit? 16:33:00 me 16:33:03 o/ 16:33:03 * shardy will be there 16:33:05 o/ 16:33:15 o/ 16:33:25 o/ 16:33:29 o/ 16:33:34 \o 16:33:45 oh, good, we'll have a nice turnout 16:33:46 o/ 16:33:49 rpodolyaka1, viktors: ? 16:33:56 dhellmann: o/ 16:33:58 cool 16:34:15 I know zzzeek said he wasn't going to make it this time around, but we can still talk about plans 16:34:32 I expect sileht and jd__ will be there, since it's only across town for them 16:34:38 :) 16:35:23 ok, I think that covers everything we need to talk about this week, unless someone has another topic they would like to raise? 16:35:56 dhellmann: I was wondering if there's a defined deprecation proces for oslo-incubator? 16:36:10 ref the request_id issues I ran into 16:36:11 shardy: sort of, yes, let me get that link 16:36:46 ah, ok, that was a special case because it shows up in config files 16:37:07 #link https://wiki.openstack.org/wiki/Oslo#Graduation 16:37:26 hrm, that's actually out of date with what we said we would do for kilo 16:38:07 we ran into issues holding old code in the incubator after graduation, because code that wasn't graduated didn't use the libraries so we had a few cases where multiple copies of code were in play in an app 16:38:20 dhellmann: Yeah I guess it was, I was just thinking if deprecation warnings typically landed before the first milestone, it would (probably) maximize the chances of most projects syncing it 16:38:28 so for kilo we decided that after the first release of a library we would delete the incubator version and update the other code to refer to the lib 16:38:43 Or, a checkpoint for removal of code from incubator could be a sanity check that projects sync'd the warning 16:38:56 I guess in non-config-impacting cases, it doesn't matter so much though 16:39:03 shardy: we are actually trying to minimize the number of syncs a project needs to do at all, so once something starts graduating we try to cut down on changes 16:39:05 A lot of projects will never sync the warning though. 16:39:15 right ^^ 16:39:23 beekneemech: Yeah, that's the problem I'm trying to solve :) 16:39:35 one of the reasons for the big push to graduate is that projects have stopped syncing 16:39:40 at first I thought only Heat failed to, but it was everyone :-O 16:39:51 once we get them onto the library, they get bug fixes without having to do anything 16:39:52 at some point there's not much in oslo-incubator so might as well auto-propose. 16:40:12 we normally sync less regularly in the latter half of the cycle, which is why we missed it 16:40:20 auto-propose would probably work for keystone once we're synced to current 16:40:42 bknudson: I thought that too, but in many cases there's API breaks which need project code fixup 16:40:43 yep, this is one of the important roles the liaisons play -- keeping projects informed of what's going on in oslo 16:40:50 or at least, historically that's been my experience 16:40:58 We really don't want to be in a place with incubator where auto-propose even works. 16:41:05 shardy: right, that's the point of the incubator is it's safe to break apis in incubated modules 16:41:06 If an API is stable enough for that, we should graduate it. 16:41:12 beekneemech: ++ 16:41:35 If we end up with no code in oslo-incubator, \o/ 16:42:38 +1 16:43:16 ok, let's call the meeting early and spend 15 minutes reviewing specs 16:43:39 Sounds good. 16:43:54 see you in Paris everyone :) 16:44:16 yes, I'm looking forward to it! 16:45:32 thanks everyone! 16:45:34 #endmeeting