15:00:37 <zns> #startmeeting satori
15:00:38 <openstack> Meeting started Mon Jul 21 15:00:37 2014 UTC and is due to finish in 60 minutes.  The chair is zns. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:42 <openstack> The meeting name has been set to 'satori'
15:01:05 <zns> Hey! Who's here for the Satori meeting?
15:03:33 <walker_> o/
15:04:27 <zns> Hi walker_
15:04:55 <walker_> One of these days I will actually fix my nick
15:05:34 <zns> samstav - you there?
15:05:41 <samstav> o/
15:06:00 <zns> Cool - let's get started. I think this will be quick...
15:06:07 <zns> #topic Action Items
15:06:22 <zns> walker_: Create a blueprint for choosing the escalation prefix?
15:06:55 <walker_> Please roll over to next week
15:07:00 <zns> samstav: Address comments on submission 9838?
15:07:05 <zns> #action: walker_ Create a blueprint for choosing the escalation prefix ("sudo" OR "su -" OR ?) when running commands in ssh.py
15:07:10 <zns> done
15:07:44 <zns> 98383 - that is
15:08:37 <zns> What is 98383, btw? samstav ?
15:08:46 <zns> Is that a bug in Launchpad?
15:09:27 <samstav> IIRC, 98383 is the primary windows submission
15:10:01 <zns> Ah, https://review.openstack.org/#/c/98383/
15:10:02 <samstav> #link https://review.openstack.org/#/c/98383/
15:10:12 <samstav> :)
15:10:26 <zns> I noticed it was failing on pep8. Has there been a break in the version of pep8 being used?
15:10:44 <samstav> Yes, and I didn't track down the root cause.
15:10:49 <samstav> I did fix it though
15:11:02 <zns> So the blocker is coming from upstream work on the testing tools?
15:11:02 <samstav> via
15:11:04 <samstav> #link https://review.openstack.org/#/c/106134/
15:11:27 <samstav> No blocker on the testing tools anymore
15:11:57 <samstav> Between submission 98383 and 106134, I ( we? ) created a conundrum
15:12:09 <zns> I was wondering if we needed a p[atch to update test-requirements and then we can rebase. You don't think that's needed?
15:13:00 <zns> ... cuz I was wondering if that is why we received https://review.openstack.org/#/c/103612/ from Longgeek?
15:13:29 <samstav> Yeah, I'm not sure about the submission from Longgeek, I thought it was just argparse?
15:14:27 <samstav> What I think it boils down to is that the original windows support submission needs the subsequent submission 106134 in order to pass gates, but it is inverse in "git" terms.
15:14:58 <samstav> Because 106134 actually depends on 98383
15:15:42 <samstav> I was hoping we could come to a conclusion about the python3 & eventlet situation, and then get 106134 passing all gates.
15:16:40 <samstav> Then we could just waive 98383, and merge 106134, and then afterwards we would have certainty that what's in the master branch is a working version that passes all gates
15:18:34 <samstav> I would not mind pushing a submission which fixes the VersionConflict & test requirements, but 98383 would still be just as far from passing all gates
15:19:08 <zns> That sounds like a good idea; just simpler to handle the version conflict alone.
15:19:34 <zns> What options we have to address eventlet and python3? Can we not use eventlet and ;et any client using satori monkey patch if they need to use event let?
15:21:41 <samstav> zns do you mean remove eventlet from requirements, and use naive method calls?
15:21:51 <samstav> e.g. try, except
15:22:48 <samstav> from eventlet import greenthread as thread
15:23:48 <zns> Yes. Just `from threading import thread`
15:24:13 <samstav> oh... monkey_patch...
15:24:17 <samstav> Right.
15:24:29 <samstav> That sounds good.
15:24:57 <walker_> I heard someone talking about asyncio as a potential replacement to eventlet, is that something we should investigate
15:25:07 <walker_> s/replacement/alternative
15:25:12 <zns> Can tunnel.py work without eventlet?
15:25:21 <walker_> https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio
15:26:02 <samstav> zns yes tunnel.py can work without eventlet, we just need to make sure we are using the methods that return immediately
15:26:29 * samstav #link https://github.com/samstav/satori/blob/testing07162014/satori/tunnel.py#L148-L149
15:26:48 <samstav> as `greenthread.spawn_n()` does
15:26:53 <zns> walker_: that's for python3 only, right?
15:27:07 <samstav> sorry, walker_
15:27:45 <walker_> It looks like it was ported to 2.7 as well - https://pypi.python.org/pypi/trollius
15:28:13 <walker_> I don't know why they chose different names though
15:28:23 * samstav is blind
15:28:55 <samstav> if "troll" in package_name:
15:29:02 <samstav> sys.exit(1)
15:29:03 <walker_> ha
15:30:21 <zns> Doesn't eventlet just patch threading to effectively mimic spawn_n?
15:30:29 <samstav> I believe so
15:31:28 <samstav> zns looks like this
15:31:30 <samstav> #link http://eventlet.net/doc/patching.html#eventlet.patcher.is_monkey_patched
15:31:41 <samstav> would tell us whether it was monkey patched by eventlet
15:31:53 <zns> So we _might_ (should?) be able to write tunnel.py using stdlib in a way that if a client is using eventlet, it should just work.
15:32:02 <samstav> thread=True
15:32:22 <samstav> eventlet.monkey_patch(thread=True)
15:33:28 <samstav> oh, jk.
15:33:36 <samstav> "If no arguments are specified, everything is patched."
15:34:10 <zns> samstav: we could just have code in there like bottlepy does: https://github.com/bottlepy/bottle/blob/master/bottle.py#L2773 - if eventlet is loaded, us it, else fail to stdlib. And don't fail on import and don't add event let to requirements.txt.
15:34:14 <samstav> Yes, we should definitely be able to do that
15:34:27 <zns> Will that address the python3 blocker?
15:34:27 <samstav> zns yes exactly that.
15:34:31 <samstav> yes
15:35:16 <zns> So that would be a change to https://review.openstack.org/#/c/98383/?
15:35:51 <zns> And we'd be able to merge that before 103612?
15:36:32 <samstav> yes
15:36:37 <samstav> and yes
15:36:41 <samstav> So, are we OK with merging the windows support submission (98383) even though it won't pass all gates, as long as a rebased version of submission 106134 ( depends on/rebases off of the 98383 ) *does* pass all gates?
15:37:22 <samstav> And, I push a submission to fix test requirements / VersionConflict
15:37:47 <zns> No - I thought we could fix 98383 by removing even let and rebasing it after we (you?) fix the VersionConlflict in a separate review?
15:38:29 <zns> Maybe I still don't understand the reason for accepting a patch that doesn't pass gates...
15:40:32 <zns> ... is there something forcing us to do that?
15:40:45 <samstav> Not "forcing"
15:41:41 <samstav> but, the only alternative is to completely re-do the work from patch 106134 into 98383, OR squash 106134 into 98383, which would remove my authorship
15:42:29 <samstav> I was trying to help move 98383 along by doing the work to make it pass gates
15:42:56 <samstav> but the gerrit workflow pretty much makes it impossible to collaborate on a patch
15:43:10 <samstav> (the only downside I've encountered so far)
15:43:32 <samstav> We really need to have both of those commits attached to the same submission with different authors
15:43:46 <zns> I see.
15:44:13 <zns> Is there a way to accept yours and have that pull in Nico's? - a gerrit question I guess.
15:44:25 <samstav> Oh... that's interesting...
15:46:22 <zns> So you're suggesting you add a new patch to fix the version conflict, merge that, rebase 98383 and remove event let from it, update yours to pass gates and merge?
15:46:51 <samstav> that is precisely correct
15:47:25 <clarkb> you can use co-authored-by and both claim authorship
15:48:50 <samstav> well
15:48:55 <samstav> thanks clarkb!
15:49:00 <zns> boom!
15:50:03 <zns> That would mean you and Nico would resubmit 98383 as a co-authored patch... with gates passing... ?
15:50:10 <samstav> ...
15:50:12 <samstav> Yes?
15:50:14 <samstav> Yes.
15:50:28 <samstav> Though, we still want a separate submission for the test requirements patch yes?
15:50:58 <zns> I think so. That would be easier to keep track of...
15:51:04 <zns> And easy to rebase also.
15:51:06 <samstav> yes
15:52:17 <samstav> Looking into the co-author thing -- that seems to be a gerrit-ism
15:52:29 <zns> Are you cool with that all on your plate? I'll help if you need me to; just let me know what I can do...
15:52:43 <clarkb> its not a gerritism
15:52:54 <clarkb> its just a git commit message header
15:53:00 <samstav> No? It doesn't seem to be built into git, and it doesn't look like GitHub will recognize that
15:53:03 <clarkb> gerrit doesnt do anything with it
15:53:32 <clarkb> but its fairly well accepted practice to use
15:53:41 <samstav> Cool
15:54:54 <zns> samstav: feel free to add your nick (or Nico's) to the commit subject if you want to make sure the contribution isn't missed outside of OpenStack statistics...
15:55:17 <zns> clarkb - thank you for the tip.
15:56:57 <samstav> ok. all good
15:58:35 <zns> Alright... so that'll do it for today!
15:58:42 <zns> Thanks, all.
15:58:47 <samstav> thanks zns
15:58:55 <zns> And thanks, samstav, for taking this on.
15:59:00 <samstav> great to have you back
15:59:35 <zns> I get to experience the timezone difference now... from Stockholm :-)
15:59:38 <zns> #endmeeting