16:10:43 <ewindisch> #startmeeting python3
16:10:44 <openstack> Meeting started Thu May 16 16:10:43 2013 UTC.  The chair is ewindisch. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:10:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:10:47 <openstack> The meeting name has been set to 'python3'
16:10:57 <dhellmann> o/
16:11:02 <ewindisch> I just got back from 2 weeks of vacation, so my calendar and brain are a bit wonky
16:11:15 <ewindisch> I'm still on CST
16:11:52 <ewindisch> I see that Chuck has been pushing a few interesting patches while I've been away.
16:12:37 <zul> yeah i have been having problems with pymox with python3
16:13:02 <romcheg> I've made an investigation on tulip
16:13:26 <ewindisch> romcheg: cool. lets dedicate some time to that, but I'd like to hear about pymox first
16:13:31 <ewindisch> #topic pymox
16:14:24 <ewindisch> zul: what is going on? I presume we're now using pymox in unit tests some/every-where?
16:14:53 <zul> ewindisch:  so pymox is basically used everywhere and its quite old so i been looking at python-mock to replace it
16:15:07 <zul> and im just learning python-mock right now
16:15:23 <ewindisch> zul: Sure. I remember this coming up in the first meeting. How is that going?
16:15:25 <romcheg> I've seen some efforts for making pymox working on py3
16:15:32 <ewindisch> ah
16:15:40 <zul> however, there is a pymox fork called mimic which is a drop in replacement of pymox
16:16:10 <dhellmann> mock and mox work differently enough, it seems like changing would probably take a lot of work, wouldn't it?
16:16:17 <ewindisch> "Experimental python3 support" -- that is somewhat encouraging
16:16:23 <zul> so last night i tried replacing pymox with mimic in oslo.config and it work great but the version on pypi doesnt support python3
16:16:29 <zul> i was looking at that this morning
16:16:41 <dhellmann> maybe we can help them get a release done?
16:17:20 <ewindisch> yeah, sounds like they might just need a bump. Having openstack using it will help eliminate that "experimental" modifier, too.
16:17:21 <zul> i think that would be a good idea im stuck in UDS this week and started looking at finishing off the mimic python3 port
16:18:23 <zul> so yeah thats where i am right now
16:18:31 <zul> comments or questions?
16:18:39 <ewindisch> interestingly, mimic seems to have added then removed python3 from the list of supported versions. There might be some regression we don't know about.
16:18:41 <dhellmann> seems like you're on the right track
16:18:56 <ewindisch> zul: I agree that mimic seems the best option.
16:19:39 <ewindisch> #link mimic-group http://groups.google.com/group/mox-discuss
16:20:00 <ewindisch> thanks zul
16:20:10 <zul> no worries
16:20:15 <ewindisch> Lets chat eventlet a bit then...
16:20:29 <ewindisch> #topic tulip investigation
16:20:41 <ewindisch> romcheg: feedback?
16:20:44 <romcheg> yup
16:20:53 <romcheg> Some bad news comming
16:21:35 <ewindisch> ?
16:21:47 <romcheg> According to my investigation tulip cannot be used as an asynchronous I/O framework for openstack
16:22:19 <ewindisch> romcheg: ever?
16:22:48 <dhellmann> yeah, you really have to be more detailed than that
16:22:51 <romcheg> Well, we need to either re-write all blocking code in OpenStack itself
16:23:34 <rpodolyaka> the real problem is SQLAlchemy we heavily rely on. Here is a very interesting answer on StackOverflow from Mike Bayer http://stackoverflow.com/questions/16491564/how-to-make-sqlalchemy-in-tornado-to-be-async/16503103#16503103
16:23:59 <ewindisch> rpodolyaka: we have those same problems with eventlet now, anyway.
16:24:31 <romcheg> It is possible to use eventlet's event loop for fixing that issue but then comes a problem with monkey patching
16:24:40 <ewindisch> a big one problem in whatever we do about eventlet is RPC, but I think we're on the right track with replacing the RPC api. The new API should make it a bit easier to swap out the async library.
16:25:21 <dhellmann> I can't find the reference, but they did update the tuplip pep (3156) at some point to remove the part that said eventlet support wasn't going to be included
16:25:31 <dhellmann> searching mercurial logs
16:25:38 <ewindisch> romcheg: couldn't someone write a monkey-patching module based on tulip?
16:25:58 <ewindisch> basically an eventlet-like solution that used tulip instead of greenlet?
16:26:46 <romcheg> ewindisch: I guess it might be easier to fix eventlet's patching then implement a new one
16:26:46 <dhellmann> right
16:27:47 <ewindisch> romcheg: basically the result is that tulip itself won't be a drop-in replacement in and of itself.
16:28:09 <ewindisch> so we still need eventlet fixed/improved or code around tulip that might be just as much or more effort.
16:29:11 <ewindisch> anything else on async lib?
16:29:53 <ewindisch> #topic grants
16:30:01 <romcheg> Well, in general a lot of code has to be written/re-written anyway
16:31:11 <ewindisch> I still have no solid ideas for grant requests.
16:31:31 <ewindisch> my best ideas are generally, "sprints" and "fixing async"
16:32:02 <dhellmann> yeah, it seems like we have a lot we can do at this point without needing grants and that when we do need them, the reason will become clear
16:32:40 <ewindisch> agreed.
16:33:17 <ewindisch> anything else, other topics?
16:33:40 <ewindisch> #topic open discussion
16:35:02 <ewindisch> I'm back from vacation now, so I'll be more engaged again, although I have a hefty responsibility on the rpc stuff at present. Again, that will help relieve the eventlet burden there, should we replace it.
16:35:39 <dhellmann> yeah, the new design should make eventlet less prominent in the rpc api and driver implementations
16:35:56 <ewindisch> zul, others… enjoy UDS.
16:36:01 <zul> tjamls
16:36:25 <ewindisch> oh, I forgot… has anyone made progress on gate tests?
16:37:29 <ewindisch> I'll take that as a 'no'. I'll follow up with Dave Ripton. IIRC, he was looking into it, but I'll check the meeting notes to be sure.
16:38:01 <ewindisch> #endmeeting