16:05:36 #startmeeting Python3 16:05:37 Meeting started Thu Apr 4 16:05:36 2013 UTC. The chair is ewindisch. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:40 The meeting name has been set to 'python3' 16:05:51 * dhellmann misread that error message and was worried he was here for the wrong meeting 16:05:54 o/ 16:05:55 so, besides me being late again - who do we have ? :) 16:06:32 hi, sorry I missed the first meeting last week and thanks for getting the ball rolling on this! 16:06:59 anyone else for the roll-call? 16:07:43 dhellmann: no problem. Hopefully the momentum can be maintained - I'm a bit concerned nobody seems to be here, though. 16:07:55 markmcclain had another obligation this week 16:08:04 being release day doesn't help, I'm sure. 16:08:14 true 16:08:25 #topic action items last meeting 16:08:26 Hello, guys! I'm with you :) 16:08:43 1. ewindisch follow up with -infra to discuss gating 16:08:49 hello rpodolyaka. 16:09:39 honestly, I didn't have a lot to do with this because markmcclain was still working on a py3 test. 16:09:49 2. markmacclain to look at writing a py3 test 16:09:55 he isn't here… so 16:10:08 #action ewindisch to chase down markmacclain, ask about py3 test 16:10:26 3. dripton to dig through oslo deps for version compat 16:10:57 dripton did this. 16:11:01 #link https://wiki.openstack.org/wiki/Python3Deps 16:11:13 ewindisch: I updated the notes from that to answer the question about stevedore or cliff (I forget which it was) 16:11:26 both should work with 3.3 16:11:33 we're targeting 3.3, right? 16:12:04 dhellmann: that isn't decided. It seems conclusive we need to support at *least* 3.2 16:12:08 ah 16:12:12 I misremembered 16:12:53 I guess we'll have to see what we can do with the dependencies before making a final call on that. 16:13:07 It was intended to review dripton's dependency analysis and use that as part basis for making a recommendation to the TC 16:13:33 4. ewindisch to look at PSF sponsorship 16:13:45 the eventlet issue is going to be painful 16:13:53 dhellmann: yeah. 16:14:12 ewindisch: did you have any luck with sponsorship? 16:14:22 I filled some missing deps on wiki and tried to make one of the deps (mox) to be compatible with both Python 2.x and Python 3.x but it has turned out to be a bit harder than I thought... 16:14:23 I did look at this. It seems we could ask for funding, if we have things that we'd want to fund. That would probably be a sprint, or perhaps seeking a PSF sponsorship for eventlet folks ;-) 16:14:55 really the question isn't if we can get money, the question is what would we use it for? 16:15:03 good point 16:15:18 sprint funding is pretty easy to get, but the OpenStack foundation could probably cover those expenses, too 16:15:39 I thought it would've been good if we had a sponsored sprint at the summit, but a bit too late for that now. 16:16:14 funding longer term development would also be something to look at, if we can identify someone interested in doing the work on an upstream dependency 16:16:50 right. eventlet specifically comes to mind. 16:17:32 and finally… 16:17:34 5. dripton create wiki pages 16:17:36 I wonder (pie in the sky) if we should just consider moving to tulip instead of porting eventlet. More "modern".  16:17:37 completed ;) 16:18:07 #topic async framework / eventlet 16:18:26 dhellmann: I'm thinking the same thing. 16:18:42 if we're going to make the leap... 16:18:50 or… porting eventlet to PEP3156 16:19:14 I don't know enough about the implementation to know if that's possible 16:19:29 how much of our code actively knows about eventlet? 16:20:05 note that if we decide to use Tulip or PEP3156, that work presently depends on Python3.3 16:20:13 There seems to be only a reference implementation for Tulip... 16:20:25 dhellmann: wsgi modules in every project, some workarounds on DB pooling... 16:20:28 dhellmann: the rpc stuff is pretty tied to it, but it could be switched out easily enough, I think. 16:20:31 romcheg: yeah, it's early but parts of it will be in python 3.4 when it's done 16:20:36 the web parts are probably more tightly coupled 16:20:42 rpodolyaka: also the rpc lib, probably? 16:20:48 dhellmann: yes, rpc. 16:21:18 ewindisch: well, that fits with my goal to have us stop using our own wsgi module in favor of pecan and wsme :-) 16:21:34 dhellmann: if we did that, we could switch off eventlet a whole lot easier. 16:21:35 the rpc bit is more troubling, but at least it is isolated if we have to make major changes 16:21:47 ewindisch: I will add that to my notes for the summit session 16:22:14 dhellmann: of course, pecan doesn't support Python 3 either. 16:22:39 are you sure? 16:22:55 well, not according to the PyPi categories. 16:23:10 ah, I'll check into that 16:23:19 the intent is certainly to support it, but maybe it's not quite there yet 16:23:32 Neither does wsme — Python 3.3 is not supported 16:23:49 christophe is quite open to patches, so we could get that updated 16:24:03 romcheg: it supports python 3.2, and very little changed there. I suspect it probably works on 3.3, or could be made to work easily 16:24:23 yeah, that's probably just a matter of updating the tox.ini file 16:24:41 ewindisch: yeah, probably easier than porting eventlet to py3 16:26:26 dhellmann: for RPC, we might be able to drop-in replace eventlet with anything else that provides (co)threading. 16:26:35 However, I know that for ZeroMQ, I used patterns that I would've avoided if not for eventlet and its behaviorisms. I'm not certain if that code would need to be rewritten, or if moving to PEP3156 would simply *allow* it to be rewritten. 16:26:59 those modules are pretty small, and the api is well defined. it might actually be simpler to just write new implementations. 16:27:16 I'd rather do a little extra work than live with extra layers of indirection 16:27:16 dhellmann: for 3156? 16:27:36 yeah, across the rpc drivers 16:27:39 not just zmq 16:27:55 I can't imagine rewriting the implementations. 16:27:59 the question is really what the upstream libraries we're using do 16:28:17 I just mean openstack.common.rpc, not all of kombu, etc. 16:29:04 it's a lot of work, but the question is whether it's better to do it or live with layers of crud for a while 16:29:39 dhellmann: I can't see rewriting or even heavily refactoring each of the impl_* files in a single release. Worse, we're talking about trying to stabilize and push these into their own library at some point. 16:30:05 dhellmann: I think that the eventlet problem has little to do with any cleanup/refactoring effort there. 16:30:14 agreed 16:30:56 anyway, we should have someone look seriously at PEP3156, eventlet, and tulip. 16:31:23 yeah, I just wanted to point out that we should consider options besides trying to force-fit eventlet just so we don't have to change our own code :-) 16:32:44 dhellmann: I agree. I honestly think that there is a chance PEP3156 could be a good thing. If we supported that, it might be configurable to choose eventlet, gevent, zeromq, or twisted eventloops. (or whatever) 16:32:55 +1 16:33:40 not sure that making that pluggable would work in practice, just as I'm not sure that anything but RabbitMQ works with our Kombu driver, but we can dream. :) 16:33:54 so if that is wrapped up… 16:33:57 :-) 16:34:52 I'd like to create an action item for someone(s) to look at tulip / pep3156 16:34:55 but there aren't many people here 16:35:07 and I think we're all busy with the summit prep 16:35:14 I can do that 16:35:18 yeah, I can't really commit to anything until after ODS 16:35:20 great! 16:35:28 romcheg: thanks! 16:35:54 #action romcheg investigate PEP3156 / tulip / eventlet issues 16:36:02 #topic meeting schedule 16:36:22 so one thing I forgot to ask last week was if this time / frequency worked for everyone. 16:36:34 it works great for me, it's right after the ceilometer meeting 16:37:10 it works great for me too, but I set the time :) 16:37:45 dhellmann: is there a reason the ceilometer meeting was split into alternating schedules? 16:38:27 we have a few core members in the Asia-Pacific region 16:38:34 it's easier for them to attend the meetings on wednesdays 16:39:00 we have to try to span Europe, US, and Australia/China (I think) 16:39:12 I thought as such. 16:39:57 well, the other issue is frequency… I didn't want to overburden people with meetings, so I set it every other week. 16:40:20 regardless, I wanted to bring this up in today's meeting, but we don't have enough people to decide. 16:40:24 deferring until after ODS 16:40:27 I think that makes a lot of sense, too. At least until we make some significant progress, I'm not sure there will be much to talk about every week. 16:40:52 #topic open discussion 16:42:11 dhellmann: agreed 16:42:28 do we have any ODS sessions planned? would it make sense to get together for an open space session, at least? 16:42:44 there is an ODS session planned. 16:42:56 good, I'll watch for that when the schedule is released 16:43:11 it is preapproved, unlike my other proposals :) 16:43:46 heh 16:44:15 dhellmann: think it would be valuable if someone did a lightning talk? 16:44:42 I don't remember lightning talks on the schedule from last time. Did I just miss them? 16:44:49 you must have missed them. 16:44:56 they've been very badly promoted 16:45:00 and attended 16:45:17 I remember them from the Folsom summit 16:45:38 hmm. I think they had them? 16:46:12 I'll follow up with Kathy or Stefano. I really hope they have them again, and better promote them as well. 16:46:25 I don't see them on http://openstacksummitapril2013.sched.org/ 16:50:16 yeah, I just sent an email to Stefano / Thierry / Kathy 16:50:41 anyway, unless there is anything else, I'll #endmeeting 16:50:56 * dhellmann has nothing to add 16:51:03 thanks romcheg, dhellmann! 16:51:05 #endmeeting