16:01:24 #startmeeting oslo 16:01:24 Meeting started Mon May 4 16:01:24 2015 UTC and is due to finish in 60 minutes. The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:27 The meeting name has been set to 'oslo' 16:01:34 o/ 16:01:45 courtesy ping for jd__, dims, bnemec, flaper87, harlowja, viktors, rpodolyaka, zzzeek, sileht, kgiusti, dansmith 16:01:45 courtesy ping for redrobot, jungleboyj, zhiyan, therve, amotoki, GheRivero, bknudson, ihrachyshka, jogo, dougwig, sreshetnyak, amrith 16:01:47 hi 16:01:50 o/ 16:01:52 o/ 16:01:52 o/ 16:01:58 sup dawgs 16:01:58 o/ (kinda) 16:01:59 o/ 16:02:01 o/ 16:02:02 dims: I need to leave in 30 min so if you need me push my topics first ;) 16:02:04 o/ 16:02:08 jd__: ack 16:02:30 o/ 16:02:38 o/ (kinda) 16:02:55 let's get started. 16:03:02 #topic Review action items from previous meeting 16:03:11 1. dims send email to -dev list requesting volunteers for liaisons (DONE) 16:03:11 2. dims to research oslo mid-cycle possibilities (IN PROGRESS) 16:03:55 i've sent out a call for liaisons, if you know anyone who may be interested, please ping them 16:04:14 #topic Red flags for/from liaisons 16:04:16 o/ 16:04:36 any fallout from the release or the uncapping of requirements? 16:04:39 None for keystone that I know of 16:04:43 hi bnemec 16:05:17 dhellmann: one question i had was not all python clients seem to have their requirements synced to global requirements for stable/kilo. 16:05:36 * stevemar sneaks in 16:05:42 * dhellmann is on the phone 16:05:57 dhellmann: ack. we can talk later 16:05:59 hey stevemar 16:06:07 switching topics 16:06:08 #topic Releases for this week 16:06:13 Anyone need releases? 16:06:28 * dhellmann hangs up 16:06:44 zzzeek: or any other oslo.db folks - Do we need https://review.openstack.org/#/c/168942/ in stable/kilo? (and put out a release) 16:06:52 dims: we are going to discuss dealing with library requirements in stable branches at the summit, so we're holding off on making any other changes 16:07:00 dhellmann: ack. thanks 16:07:02 hey 16:07:08 sorry someone knocked on my door 16:07:19 i dont think this is critical for kilo 16:07:48 zzzeek: so we should not merge it unless we want to release it. (i think!) 16:07:53 right dhellmann? 16:08:04 dims: I had down on my todo list an oslo.middleware release for this morning, and ended up side-tracked with summit planning 16:08:16 dhellmann: i can take care of that 16:08:37 #action dims to release oslo.middlware 16:08:46 dims: cool, thanks -- normally I wouldn't mind doing it, but today got away from me 16:08:53 zzzeek: ok with holding up that review? 16:08:57 dims: yes 16:08:59 thanks 16:09:13 anyone else have things that got merged in stable/ branch? 16:09:22 and needs a release, please ping me later 16:09:33 #topic Ongoing work & Review priorities 16:09:35 dims: we shouldn't need anything to test with alpha versions of sqla in stable branches because we won't use alpha versions there 16:09:47 dhellmann: ack 16:10:05 jd__: floor is yours, you had stuck reviews 16:10:27 what, you want me to whine about all my reviews? awesome! 16:10:32 lol 16:10:39 * harlowja_at_home gets the popcorn ready 16:10:47 yep. i think you had 2 that had conflicts :) 16:10:55 I think the main issues is this one: https://review.openstack.org/#/c/148500/ 16:11:12 it seems we agree that the patch is OK but how to propagate that in other projects is a problem 16:11:24 as said on openstack-dev, I wrote a couple of patches already and getting the merged is… complicated 16:11:31 I don't think keystone is using strtime 16:11:57 basically if we deprecated before removing usage, logs are flooded and people complain, and if we try to remove usage before deprecating, nobody cares 16:12:13 anyone has a better plan? :) 16:12:17 ./keystone/token/providers/common.py: 'issued_at': timeutils.strtime(), 16:12:19 actually, it is. 16:12:21 jd__: so let's do #1 :) let them complain :) 16:12:31 https://review.openstack.org/#/c/177848/ i guess is connected/related (if we really decide PendingDeprecationWarning is better than DeprecationWarning) 16:12:35 what I'm doing with the namespace patches is submitting them, and then I'll submit changes to our libraries with Depends-on set to the patches in the other projects 16:12:46 dims: dhellmann thinks that this does not help Oslo reputation (and I understand that) 16:13:03 right, when we make it look like we're spamming the logs or breaking the gate, it makes projects think twice before using our libraries 16:13:14 Could we mark it deprecated in the docstring first so we have something to point at when we submit patches to other projects? 16:13:22 dhellmann: well but nobody will care about your patches :( 16:13:22 bnemec: I like that 16:13:27 Then once we think we've got it everywhere turn on the warning. 16:13:30 jd__: some of mine are already merged, actually 16:13:40 dhellmann: lucky you :p 16:13:47 dhellmann: I guess those are less controversial 16:13:48 although in my case it has been an ongoing project, so there's more awareness 16:13:49 yeah 16:13:51 bnemec: +1 16:13:58 bnemec: that might be a good plan 16:14:06 if it's proposed to keystone I'll put it on my short list 16:14:13 bknudson: thanks! 16:14:16 we can also ask for liaisons to help with patches, so jd__ doesn't have to write them all himself 16:14:30 mine are mostly mechanical, so I have a script that produces them so I don't mind doing it myself 16:14:41 jd__: which project did you have most trouble with? (cinder?) any help from liaison? 16:14:42 my reviews in keystone take a long time to merge since I can't +2 them. 16:15:04 bknudson: throwing a hint at keystone cores? :) 16:15:11 dims: CInder mainly, and nova a bit too 16:15:19 bknudson, you have too many to review :P 16:15:22 jd__: I also suggest including in the commit messages in the other projects a deadline after which we're going to consider the deprecation in effect. In this case that would mean saying something like "we will add a deprecation warning to the logs after L-2" or whatever deadline you pick 16:15:23 it's a hint to jd__ that it would be better if he submitted it 16:15:33 dims: I didn't try reaching liaison, my past experiences discouraged me 16:15:58 but I'm clearly not going to write any more patches at this stage 16:16:04 jd__: y, i'll pester^H^H^H^H^H^Hencourage them jd__ 16:16:05 so yeah, liaison that's a work for you 16:16:28 jd__: see https://review.openstack.org/#/c/178281/ for example 16:16:31 is there a bug already? 16:17:51 bknudson: about strtime? no 16:17:56 dims: maybe we should write up a generalized version of this process for future reference 16:18:04 part of the point of strftime is that we can override utcnow and get the same time all over 16:18:10 dhellmann: spec or wiki? 16:18:16 bknudson: that's still covered 16:18:20 dims: we moved all of our policies to the spec repo, didn't we? 16:18:25 y 16:19:10 dhellmann: if you have some notes, i can turn it into a spec, since am sure you are busy with summit work 16:19:10 dhellmann: dims: I think it's a good idea. It's a bit sad, but it seems we need to have policy and things that make some kind of authority to push things forward and remove technical debt in the project 16:19:56 python warnings also provides a pending deprecation warning 16:20:20 dims: I think just the discussion from this meeting, although I could give you more detail on justification for not just throwing deprecation warnings around 16:20:40 dhellmann: cool, i'll get started and you can throw your notes in comments 16:20:42 bknudson, https://review.openstack.org/#/c/177848/ ;) 16:20:43 jd__: the point of writing it down is to say to the next person, "this is what we figured out that works" 16:20:57 harlowja_at_home: nice! 16:21:00 :) 16:21:01 dims: sounds good 16:21:03 #action dims to write up how to deprecate better to avoid adoption issues 16:21:21 Wasn't this also going to be a summit topic? 16:21:28 also, please touch up reviews (kilo->liberty) 16:21:38 harlowja_at_home: once you release that I'll rework my patch to use it :) 16:21:43 so, short term, if jd__ submits a patch to just document the deprecation I will +2 that so we can point to it as "fact" for anyone objecting to patches anywhere else 16:21:45 y bnemec, trying to put together so we can talk more at summmit 16:21:47 jd__, sure thing boss 16:22:07 dhellmann: is doc + PendingDeprecationWarning ok? 16:22:14 dhellmann: or does it spam too? 16:22:15 so I just want to be clear on one thing -- you all agree that strtime is going away? 16:22:22 because the review has a -2 on it. 16:22:34 jd__: I don't know if it generates multiple log messages or not :-/ 16:22:47 bknudson: yes, i believe it was a procedural -2 16:22:47 dhellmann: ok! I'll give it a try 16:23:06 * dims takes back floor :) 16:23:16 go ahead dims :) 16:23:16 bknudson, dims : right, I wanted us to work out the process first 16:23:27 specs, please touch up from kilo -> liberty 16:23:28 #link https://review.openstack.org/#/q/project:openstack%2Foslo-specs+is:open,n,z 16:24:15 anyone wants to bring up any spec for a quick discussion? 16:24:44 k 16:24:47 #topic liberty planning 16:24:56 anyone have conflicts that i need to address? 16:25:05 #link https://etherpad.openstack.org/p/liberty-oslo-summit-planning 16:25:06 #link https://libertydesignsummit.sched.org/overview/type/design+summit/Oslo 16:25:22 if someone can't make it to a session and wants me to present their POV, let me know please 16:25:28 or man those titles are super-awesome, haha 16:25:32 *oh mn 16:25:34 *oh man 16:25:37 harlowja_at_home: ++++ 16:25:41 lol 16:25:53 i will populate descriptions today 16:26:04 #topic Open discussion 16:26:26 so nova has a tool for abandoing reviews - i was trying to see if it will be useful for us - https://review.openstack.org/#/c/179780/ 16:26:51 old stale reviews basically 16:26:57 12 weeks with a core reviewer blocking with -2 16:27:01 so another library that oslo could adopt, tardis (unless people have a better name); bascially the code from https://github.com/openstack/taskflow/blob/master/taskflow/types/futures.py 16:27:03 12 weeks without comment and failed Jenkins test 16:27:07 dims: how many reviews does that apply to? 16:27:08 just wanted to fyi people on that 16:27:22 http://sourceforge.net/p/pypi/support-requests/494/ (me trying to get name of that pypi package back from dead? owner) 16:27:25 dhellmann: this morning yielded about a dozen or so 16:28:10 oslo.messaging i think wants to use/share that (so hopefully can have that for liberty) 16:28:20 so far only the following projects 16:28:20 oslo doesn't have friday meetup? 16:28:21 PROJECTS="(project:^.*openstack/oslo.*)" 16:28:34 ok. I'm not generally in favor of auto-abandoning reviews. I used to be, but the case has been made by different folks on the mailing list that it's somewhat socially hostile, and so I've changed my mind. 16:28:51 harlowja_at_home: sounds good! do we need a spec or just a blueprint? 16:28:58 dhellmann, oh, i should do that 16:29:10 dhellmann, just BP should be sufficient 16:29:21 dhellmann: how do we raise awareness to old reviews? is there a better way? 16:29:22 bknudson: no, I don't think we asked for one because usually people need to work in their other projects then 16:29:23 or that to, i'm ok with whatever :-P 16:29:39 dhellmann, I have already a PoC for oslo.messaging that replace the executor code with the taskflow lib 16:29:45 dhellmann: should it just add a message and not abandon? 16:29:48 dims: we could work on a dashboard query, and maybe get someone to volunteer to pick a few to highlight each week at the meeting? 16:30:14 i can throw a quick-spec together though if people want, no biggie 16:30:15 dims: adding a message is good, sure 16:30:16 This is only to abandon things that _cannot_ merge though, right? 16:30:23 Not things that need review. 16:30:28 harlowja_at_home: +1 16:30:34 harlowja_at_home: it's sort of nice to have a vote recorded to show the support for taking on the maintenance work 16:30:41 ok dokie 16:30:45 bnemec: right, either -2 from core or -1 from jenkins 16:30:48 but it's also pretty obvious that we'll do it :-) 16:31:01 #action harlowja_at_home do spec for tardis (or whatever it will eventually be called) 16:31:21 bnemec: right, and we could set up the dashboard query to ignore those so we just don't see them if that's the issue. 16:31:40 harlowja_at_home: under oslo namespace? 16:31:53 eck, doesn't seem needed 16:31:57 I think this is intended to be standalone 16:32:05 do we need a spec then dhellmann? 16:32:35 dhellmann: Yeah, I just think we're talking about two completely separate sets of reviews - unmergeable ones that would be auto-abandoned by the tool, and old reviews that just need reviewer love. 16:32:43 dims: well, on the one hand we're asking the team to sign up for additional maintenance work so it's nice to make that explicit. OTOH, we could just vote in the meeting or something. 16:32:45 make as standalone as we can, and if can't then oslo namespace (but i forsee future where not needed to do that, hopefully) 16:33:10 harlowja_at_home: ack 16:33:12 dims: we don't *need* a spec in this case, since we're just moving code from one place to another 16:33:30 dhellmann: +1 16:33:45 dims, imho its similar to https://review.openstack.org/#/c/141961/ (which is yet another standlone library like thing) 16:33:52 Is there any api work needed though? 16:33:57 This is kind of like a graduation. 16:34:04 right 16:34:26 right, the other point of the spec would be to document any additional work that needs to be done 16:34:27 no api work needed afaik, i write perfect code obviously, lol 16:34:33 heh 16:34:35 :-) 16:34:36 haha 16:35:03 so if we don't think we need a spec, that's fine -- it's a tool for the team to decide how to use :-) 16:35:16 i write one anyway 16:35:19 not especially tough :-P 16:35:42 ok switching topics then 16:35:44 people can -2 it if they want (and tell me to put it in garbage bin), either way 16:35:44 #topic Open discussion 16:36:07 oops, we are already in open discussion :) 16:36:26 more discussion! 16:36:42 more open! 16:36:47 yay! 16:36:50 ha 16:36:51 +open 16:36:58 who is excited about Go stuff in swift? :) 16:37:09 :-/ 16:37:13 do we want to experiment with something? 16:37:24 we'll need to redevelop all of oslo in go 16:37:30 i'm more on the meh side of it honestly 16:37:31 and a lot of python libraries 16:37:38 Nah, swift doesn't use Oslo anyway. :-) 16:37:58 swift has always been special, i guess they want to be more special, idk 16:38:19 haha 16:38:20 wow 16:39:13 dims: opened a can of worms here ;-) 16:39:35 to each there own though, just brings back memories of zookeeper and java ( http://lists.openstack.org/pipermail/openstack-dev/2013-October/017916.html ) 16:40:09 notmyname fwiw, i am interested in the experiement and learning! 16:40:16 where can i pay attention? 16:40:55 dims: we've got a feature/hummingbird branch in the swift repo. and code will be in gerrit. and we'll talk in vancouver. of course in #openstack-swift. normal "talk about code" places. 16:41:20 notmyname: thanks just wanted to be sure 16:42:13 flaper87: i saw a thread on pecan/falcon etc. any oslo implications there? 16:42:26 dims: none 16:42:31 #link http://markmail.org/message/zqw4fijc4tmhhwup 16:42:50 thanks flaper87 16:42:58 that's all i had in terms of general news 16:43:17 let's wrap it up then 16:43:17 np :) 16:43:23 woot 16:43:28 thanks everyone 16:43:30 #endmeeting