16:00:07 #startmeeting oslo 16:00:08 Meeting started Fri Sep 19 16:00:07 2014 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:11 The meeting name has been set to 'oslo' 16:00:17 who's around for the oslo meeting? 16:00:18 o/ 16:00:22 o/ 16:00:23 o/ 16:00:25 o/ 16:01:07 hi 16:01:09 \o 16:01:18 o/ 16:01:24 o/ 16:01:31 as usual our agenda is in the wiki: 16:01:35 #link https://wiki.openstack.org/wiki/Meetings/Oslo 16:01:43 #topic Review action items from previous meeting 16:01:48 dhellmann review all libs for unreleased changes that need to go out on monday 16:01:50 DONE 16:01:53 we have released all the things 16:01:58 \o/ 16:01:58 w00t 16:02:25 good work, everyone! 16:02:56 #topic Red flags for/from liaisons 16:03:00 ok, what'd we break? :-) 16:03:27 is anyone reporting issues with the final releases? 16:04:20 I see a few critical bugs: 16:04:21 #link https://bugs.launchpad.net/oslo/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes 16:04:21 .used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on 16:04:27 ouch 16:04:40 http://bit.ly/1o9f8F6 16:04:42 #link http://bit.ly/1o9f8F6 16:04:42 I haven't seen any bugs to keystone since the oslo libs release 16:05:17 there is a review for https://bugs.launchpad.net/oslo.db/+bug/1330763, let me find 16:05:18 Launchpad bug 1330763 in oslo.db "PostgrestSQLOpportunisticFixture fails with no attribute named _details" [Critical,Triaged] 16:05:22 the pbr bug blocked us from releasing pbr, so it would be good to have some reviews on that -- maybe we can do a release right after the other projects finish their releases 16:05:39 this one https://review.openstack.org/#/c/120923/ 16:06:02 ok, I"ll mark that as in progress 16:06:23 which also, when we ever get to my test rework, is also fixed :) 16:07:18 bknudson: ok, good to know 16:07:48 Does anyone have time to fix up that oslo.db change? 16:07:56 It's still broken if you run locally. 16:08:00 dhellmann: pbr review has 2 +2's not sure why it's not +W'ed https://review.openstack.org/#/c/122234/ 16:08:18 dims_: I think because those +2 came before the test jobs finished 16:08:20 is this fix still considered part of juno ? 16:08:39 zzzeek: if we need to provide it for the juno versions of the other projects, then it would be 16:09:45 zzzeek: is that failure happening regularly? why is this old of a bug marked as critical? 16:09:59 dhellmann: not sure. i think the nova folks got into it 16:10:04 ok 16:10:20 let's see if we can close that out, and I'll talk to ttx about the most appropriate way to release the fix next week 16:10:49 same for pbr 16:11:05 #action dhellmann talk to ttx about timing for oslo.db and pbr releases 16:11:22 #topic Juno Retrospective 16:11:30 We have some good notes in the etherpad I sent out yesterday 16:11:31 #link https://etherpad.openstack.org/p/oslo-juno-retro 16:11:49 beekneemech, https://review.openstack.org/#/c/120923/ fixed ... 16:12:48 some of these items deserve more discussino than I think we'll have time for here in the meeting 16:12:51 harlowja_at_home: Thanks 16:13:06 dhellmann: there was a vote for rados on mailing list, can you please add him as oslo.vmware specialist? 16:13:13 dims_: sure 16:13:23 #action dhellmann add rados to oslo.vmware core list 16:14:14 if you've been holding onto an idea for a way to improve the way we work, this is the time to bring it up :-) 16:14:30 make oslo sexy! 16:14:30 does anyone have questions about any of the items on the list so far? 16:14:40 dhellmann: "super +1" concept, we can formalize it? 16:14:49 dhellmann: http://markmail.org/message/hhld2vhk2sciwcba 16:14:50 dims_: super +1? 16:15:04 * beekneemech coined a phrase, apparently :-) 16:15:04 * dhellmann is behind on the ML 16:15:12 beekneemech: :) 16:15:18 I just sent it like 20 minutes before the meeting 16:15:43 beekneemech: i liked it a lot :) 16:16:30 beekneemech: I think I like that, too. We'll have to think about how to implement it in practice, like remembering who gets the ++1 vs. +1 16:16:31 It seemed to work reasonably well for incubator. 16:16:47 dhellmann: right 16:16:48 maybe just a maintainers file for the drivers 16:16:48 +1 16:17:03 +1 to maintainers file 16:17:05 +1 to maintainers file 16:17:07 we could also encourage some of those driver authors to become oslo.messaging cores :-) 16:17:09 Heh 16:17:29 dhellmann: That would be nice. 16:17:33 basically we build pool of folks we can co-opt! 16:17:44 dims_: sssh, you're going to give away the secret plan! 16:17:49 :) 16:18:49 ok, beekneemech, would you post those extra details to the list? we can get the other oslo messaging devs to comment that way before going ahead with the plan 16:19:11 would this effect spinning out the drivers into separate (sub) projects? 16:19:15 dhellmann: Sure. 16:19:25 kgiusti: this is an alternative to doing that, yes 16:19:26 eg - would it eliminate that need? 16:19:29 ok 16:19:44 kgiusti: i hope it would eliminate the need for git sprawl 16:19:51 +1 16:19:58 kgiusti: that's still an option, but the project management and integration test load goes up every time we add a repository 16:20:10 +1, I'm leery of bit rot 16:21:29 is there anything else on the retrospective list we should talk about now? I'll post to the ML for more discussion, too. 16:22:12 I wanted to point out in the retrospective how much code we got out of keystone 16:22:24 I saw that, that's excellent! 16:22:30 bknudson: great stat 16:22:30 dhellmann, i'm always ok with more taskflow reviews ;) 16:22:32 this is great for security. 16:22:51 Heh, less vendorized Oslo code ftw. ;-) 16:22:56 harlowja_at_home: yep, we need to build up the review team for that lib beyond just core 16:23:02 beekneemech: +1 16:23:03 beekneemech: y, we don't need that complaint 16:23:57 dhellmann, agreed, glance is starting to suck it in/use it, so it'd be nice to figure out how to involved cinder/glance more in the whole process (get ambassadors from them...) 16:24:21 harlowja_at_home: that sounds like a good way to build the team up 16:24:38 ya, even if they are semi-active 16:24:47 yep 16:25:12 * for those interested, https://review.openstack.org/#/c/85211/ 16:25:24 there's a lot of active development going on there, so it should be easy to attract people if we look in the right places 16:25:51 agreed 16:26:20 let's move on then 16:26:21 #topic Looking ahead to Kilo 16:26:48 dhellmann: is there consensus on yanking py26 support? 16:27:10 dims_: I think we're waiting on SuSE. I expect infra will keep us informed about that. 16:27:30 I think in atlanta we basically said no py26 for kilo 16:27:42 it was twittered so must be official now 16:27:49 :-) 16:27:54 clarkb: that's what I remember, but I wasn't sure who would be responsible for actually implementing that across all of the projects. 16:27:55 clarkb: lol 16:28:07 one thing to keep in mind though is that the clients must still py26 for old releases 16:28:23 so clients and possibly oslo may py26 for another year 16:28:26 so that means at least some of the oslo libs will have to be tested for 2.6 16:28:31 yup 16:28:44 oslo.utils, oslo.serialization (?), maybe some others -- we will have to do that analysis 16:28:52 stevedore and cliff 16:29:07 Might be safest just to leave them all. They're all being tested against 2.6 now anyway. 16:29:26 yeah, we know some of the libs are only used in the servers, but it's just as easy to keep them all for now 16:30:00 as some of you know, markmc is going to be focusing on some internal work at red hat for kilo, so he has stepped down as the lead on oslo.messaging 16:30:12 I've asked sileht to take over those responsibilities, and he agreed 16:30:25 #info silent is our new lead for oslo.messaging 16:30:30 sileht++ 16:30:34 dhellmann: +1 to sileht 16:31:17 clarkb: while we have you, i saw notes on py34 is that as a replacement for py33? 16:31:43 dims_: oh, yes, good question -- I think I saw mention that we had a project failing the tests under 3.4? 16:31:52 oslo.utils dhellmann 16:32:04 hrm, that's surprising 16:32:05 i was gonna try to fix that today unless someone else is working on it 16:32:06 do we have a bug filed? 16:32:09 I think we are leaning that way. aside from f20 py33 does not have a large install base but 34 is going to be in lots of stuff? 16:32:18 dhellmann, i can open one with the details of whats broken 16:32:22 *once i get into work 16:32:27 clarkb: picking one version of py3x makes sense to me 16:32:37 harlowja_at_home: ok, thanks 16:32:50 #action harlowja_at_home open a bug to track fix for oslo.utils py34 test job 16:32:51 anyways we would like to shift the bulk of py3k testing to 34 because its easy for us to test and easy for users to consume 16:32:59 ++ 16:33:04 np, the part that made me sad was the we published oslo.utils on pypi with stated py33 support but its still not voting :-/ 16:33:22 harlowja_at_home: nice seque 16:33:26 segue 16:33:28 harlowja_at_home: y the comments from clarkb and fungi were on that review i had for making them vote 16:33:32 #info we need to wrap up some details for our new libs: https://docs.google.com/spreadsheets/d/1MvXsg0XxPonJ8yAFSraIwHM940eAfoXhfBVRa6hN7MY/edit#gid=0 16:34:10 we have a few doc items to connect, a few jobs to make sure we have set to voting, etc. We should prioritize that work now, so we're completely done with what we started in Juno before we start the Kilo work. 16:34:22 dims_, yes i know comments on review for infra, still made me a little sad :-P 16:34:31 please look over the list of incomplete items for your libs on that spreadsheet 16:34:41 dhellmann: related question, what is the next set of code to library-ize? 16:34:51 dims_: we need to work that out 16:35:06 is oslo.concurrency released for juno? 16:35:07 I plan to do some work on that next week, and start a discussion on the ML 16:35:17 sounds great 16:35:31 dims_: if you have ideas, let me know :-) 16:35:51 dhellmann: ack :) 16:35:51 bknudson: we had a pre-1.0 release, but it's not marked as final on https://etherpad.openstack.org/p/juno-oslo-feature-freeze 16:36:08 Okay, and we can unblock all of the stuff like https://review.openstack.org/#/c/118218/ right? 16:36:27 boy, you guys are 1 step ahead of me today 16:36:28 #info it is time to start removing deprecated code from the incubator 16:36:36 Heh 16:36:37 unleash your git rms 16:36:53 lol 16:36:57 Ooh, it's rpc delete time, right? 16:37:00 we'll need to coordinate, so that we update the modules that stay behind to use libraries appropriately 16:37:05 So we can go back to having sane tox envs. 16:37:06 oh, yes, please, please delete that first 16:37:16 hehehe 16:37:22 jd__: has a patch up for that, and we need to ressurect it and make sure it's still correct 16:37:51 #info while we are deleting code, fixes to incubated code needed by the other projects will need to be applied to the new stable/juno branch 16:38:00 dhellmann: don't see oslo.concurrency here - https://review.openstack.org/#/c/121621/ 16:38:07 we'll have to decide on a case-by-case basis where to apply a patch first 16:38:25 dims_: ah, I can abandon that one, we landed 2 other patches instead 16:39:00 nice 16:39:00 abandoned 16:40:16 dims_: you have a patch somewhere to update the incubator to use oslo.utils, right? 16:40:28 dhellmann: y will freshen it up 16:40:33 ok 16:41:07 one of the things I'd like us to try for kilo is using launchpad for scheduling work with bugs as well as blueprints 16:41:18 so let's file some bugs for the delete work, and put them in the appropriate next-kilo milestone 16:41:30 maybe one bug per library? 16:41:38 associated with the incubator project 16:42:03 Seems reasonable 16:42:43 that will also let us start using the launchpad milestone as a way to figure out what reviews to prioritize 16:43:17 we dont need bugs for every little change, but for things we agree are team priorities it helps to have a list somewhere 16:43:28 and etherpads were really not scaling well 16:44:07 So. many. etherpads. 16:44:15 lol 16:44:24 ttx created a nice release script for us that closes the milestones, marks the bugs as "fix released", and then tags the repository 16:44:36 library releases will be much less manual during kilo :-) 16:45:13 one last item 16:45:14 #topic review priorities for this week 16:45:20 #info incubator cleanup 16:45:26 #info any critical bugs 16:45:30 #link http://bit.ly/1o9f8F6 16:45:47 do we have any changes in play without bugs on that list? ^^ 16:46:17 not that i know of 16:46:28 nothing critical from my side 16:46:46 beekneemech, you asked about lower priority changes earlier. do you think it makes sense to do the cleanup work first, then deal with merge conflicts to those changes. 16:46:49 ? 16:47:18 Hmm 16:47:37 Probably. There's no sense reviewing changes to code that will be getting deleted. 16:47:38 or should we merge the little stuff to make it easier to backport them? 16:48:00 yeah, let's see what we actually have -- some of it we might just ask to have merged in the stable branch and not in master at all 16:48:05 Well, backports to code getting deleted are going to skip master anyway, right? 16:48:11 right 16:48:26 I was thinking of a case that was mixed 16:48:38 there was something recently, let me find it 16:49:00 Yeah, but we'll end up with a messy backport for those anyway since some of the files will have disappeared either way. 16:49:13 true 16:49:27 oh, the mock thing: https://review.openstack.org/87375 16:49:38 that one we probably don't care so much about backporting 16:50:17 Yeah, I wouldn't think so. 16:50:36 ok, do we want to sign up to work on the deletion stuff so we don't step on each other's toes? 16:50:59 Seems like a good idea. 16:51:04 I'm out Mon-Wed next week though. 16:51:21 #link https://etherpad.openstack.org/p/oslo-kilo-deleting-graduated-libraries 16:51:59 we need one etherpad where can we can write down the urls to the rest of them :) 16:52:41 dims_: haha 16:52:49 One etherpad to rule them all! 16:53:08 you know, I just said we'd use bugs for this 16:53:15 * dhellmann needs to stop making etherpads 16:53:27 Heh 16:53:35 sign up on the etherpad, and then create a bug and assign it to yourself :-) 16:53:41 lol 16:54:52 that's all I had for today 16:54:56 #topic open discussion 16:55:09 dhellmann: Oh, so stuff like https://review.openstack.org/#/c/118218/2/MAINTAINERS will need to go to stable/juno instead of master now. 16:55:20 Because those modules will get deleted entirely in master. 16:55:28 so i really want to fix up the way libs use EngineFacade 16:55:45 because i see like in nova, get_engine() / get_sessino() called all over the place, repeatedly, overlapping, etc. 16:55:49 beekneemech: good point. Do you think we still need that at all? or is it clear from the fact that we've deleted the code that it is obsolete? 16:56:35 zzzeek: you have doc on proper usage? i'd be happy to apply it to ceilometer 16:56:46 gordc: i have to blueprint some new API 16:56:56 so i want to make a BP taht pushes for a decorator 16:56:57 beekneemech: the "obsolete" status was meant to be used for code we were keeping around after graduation, which we won't be doing any more 16:57:12 zzzeek: cool cool. that sounds like a good idea. 16:57:17 there would no longer be any get_session() or get_engine() calls, it confuses everyone. 16:57:22 dhellmann: Yeah, that makes sense, and it would cut down on the number of boilerplate changes we have to make. 16:57:27 the decoator would maintain just one transaction no matter how much it is nested 16:57:29 beekneemech: right 16:57:45 and could also do the “retry on failed transaction” thing, perhaps with some declarative markers whether or not to enable it for a series of methods 16:57:48 #action dhellmann update graduation instructions to say delete code instead of marking it obsolete 16:57:51 zzzeek: how? thread-local variable? 16:58:10 bknudson: the decorator would maintain the state as it calls the wrapped function 16:58:27 zzzeek: that spec sounds like interesting reading :-) 16:58:52 dhellmann: its a pretty simple idea, but it means, if you want the DB you would use this decorator, and it feeds an extra argument into your funciton 16:59:01 ive looked at neutron, they already have a system like this 16:59:15 well they have a “context”. 16:59:24 zzzeek: nice, maybe we can bring theirs into oslo 16:59:26 so they probably woudlnt use this part of it. 16:59:29 maybe. 16:59:48 that might make some keystone stuff easier, since we have cross-backend calls 16:59:55 but i still see reviews daily, that confuse get_engine(), get_session(), begin(), and i think it should all be removed from code that uses oslo.db 17:00:00 the called backend might be SQL or it might be LDAP 17:00:08 we're almost out of time, so I want to say THANK YOU ALL once again for a highly productive cycle 17:00:28 woop 17:00:40 +1000 to all of us :) 17:00:51 ++ 17:00:58 ok, time's up 17:01:01 #endmeeting