19:02:15 <mtaylor> #startmeeting
19:02:16 <openstack> Meeting started Tue Jan 24 19:02:15 2012 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:23 <mtaylor> #topic OpenStack CI Meeting
19:02:29 <mtaylor> hey all - what's up?
19:02:35 <adam_g> o/
19:02:39 <LinuxJedi_cell> The sky
19:03:10 <mtaylor> awesome
19:03:14 <mtaylor> it's good that the sky is up
19:03:30 <LinuxJedi_cell> True :)
19:03:57 <mtaylor> so - LinuxJedi_cell and ttx were chatting earlier and had a couple of questions about gerrit review voting
19:04:53 <mtaylor> a) can a -2 vote be overridden
19:05:28 <mtaylor> b) why do we need a +2 vote in addition to the approval vote
19:06:13 <mtaylor> the answer to a) is really easy ... "no"
19:06:14 <mtaylor> :)
19:06:41 <LinuxJedi_cell> Well, more why can't it for a)
19:06:42 <mtaylor> a -2 is a hard blocker vote which is essentially saying "over my dead body will this go in, you will have to convince me first"
19:07:06 <LinuxJedi_cell> Lol! OK :)
19:07:25 <mtaylor> which is a thing that has been requested in the past (and then we got lucky because it already worked that way0
19:07:28 <_0x44> mtaylor: +2 is needed to distinguish -core from +1 reviewers...
19:07:37 <mtaylor> -2 is the only vote which persists across new patches
19:07:50 <mtaylor> and _0x44 is correct about purpose of +2 votes
19:08:26 <mtaylor> also, if a core reviewer is adding the second review and hitting approve, having them go ahead and add the +2 just makes it clear who the people who voted +2 were later on
19:09:01 <mtaylor> LinuxJedi_cell: does that help?
19:09:18 <LinuxJedi_cell> Very much so, thanks
19:09:34 <mtaylor> of course - they did bring up the issue of a core reviewer voting -2 and going awol, but hopefully we won't have awol core devs too much
19:10:08 <mtaylor> #topic expiration of old reviews
19:10:34 <mtaylor> for those who weren't paying attention first thing this morning, the expire-stale-reviews work that LinuxJedi_cell did went live last night
19:11:23 <mtaylor> so now code reviews that are old and crusty will get marked abandoned.
19:11:27 <mtaylor> if a dev really does want it around, they can always go to it and click "unabandon"
19:12:36 <mtaylor> the rules are currently that any patch that has no activity in 2 weeks is marked abandoned, and any patch with a negative review and no activity for 1 week is marked abandoned
19:12:55 <mtaylor> obviously, as this goes on, if those seem either too lax or to strict, they can be adjusted
19:13:48 <mtaylor> #topic narcissism, or report from LCA
19:14:15 <mtaylor> jeblair and I went and spoke at Linux Conf Australia last week about the OpenStack gerrit and jenkins setup
19:14:42 <mtaylor> the talk went really well, if you can't go to sleep one night and want to be bored, it is on youtube
19:15:33 <mtaylor> but as a result we learned that there are several folks who are implementing our system for their dev environments, either by following our code, or in one case we're talking about making sure that our puppet modules are done in a way that they can consume them directly
19:15:50 <mtaylor> so that's great- more people poking around at things is always great
19:16:45 <mtaylor> #topic tox, bundles and multi-version support
19:17:44 <mtaylor> also, we've got jobs in jenkins that do a proof of concept of using tox to drive virtualenv building and testing - and that use pip bundles as the package caching method rather than trying to do relocatable virtualenvs
19:18:15 <mtaylor> (turns out that virtualenvs just aren't properly relocatable - and really the --relocatable option for virtualenv is an outright lie)
19:18:53 <mtaylor> the pip bundle part of that is a replacement for the current process we do of making a clean virtualenv, tarring it up and then untarring it at the start of jobs
19:19:19 <mtaylor> which we do to avoid pulling network resources during test runs (gives us quicker speed and also less false negatives)
19:20:20 <mtaylor> tox replaces install_venv.py and with_venv.sh with a tox.ini file, and then handles the creation of the virtualenvs. out of the box it allows us to do multiple python versions (right now doing 2.6 and 2.7)
19:21:05 <mtaylor> the plan is to get a few more infrastructure pieces done this week (a set of new builders) so that we can start proposing migrating projects over ... most of them work right now
19:21:14 <mtaylor> nova not so much for reasons I still don't understand
19:21:37 <mtaylor> #topic open discussion
19:21:41 <mtaylor> anything else from anybody?
19:21:45 <adam_g> hi
19:21:47 * LinuxJedi home now
19:21:50 <mtaylor> hey adam_g
19:21:52 <mtaylor> hey LinuxJedi
19:21:58 <LinuxJedi> hey
19:22:05 <adam_g> so, we've got our 12 node CI rig up and running, building packaging and trigger jobs based on upstream commits
19:22:13 <notmyname> I've got a couple of things
19:22:40 <notmyname> (but I may have forgotten one)
19:22:41 <adam_g> at UDS, we discussed possibly hooking this into the upstream jenkins infrastructure, to trigger jobs on our systems and collect upstream, is that right mtalor?
19:23:23 <mtaylor> adam_g: yes. I would love to do that
19:24:24 <mtaylor> adam_g: simplest way from my end would be to get a jenkins slave that runs the driver jobs, and then get your jobs moved/copied in to our jenkins (And give  you access to edit them)
19:24:25 <adam_g> mtaylor: has this happened yet with any other downstream parties, or is this the first? im curiosu to know when/waht would be triggering jobs, and what information you'd be interested in getting back. our setup is more complex than the devstack-driven single node tests, so i dont want to flood you with garbase
19:24:28 <mtaylor> I don't know if that meets your needs
19:24:59 <mtaylor> adam_g: we've started the process with a few other downstreams, none of them have actually started running tests though :(
19:25:17 <notmyname> mtaylor: when not logged in to review.openstack.org, there are nice little copy widgets. they aren't there when I am logged in (minor bug perhaps)
19:25:33 <adam_g> currently we're running a subset of the devstack tests, but hope to have tempest hitting the cluster as well for every deployment soon
19:25:43 <mtaylor> notmyname: there is a preferences setting for copy widgets ... one sec
19:25:45 <Kiall> notmyname: thats a preference for your gerrit account
19:25:53 <notmyname> ah. interesting. thanks
19:25:54 <Kiall> "Use Flash Clipboard Widget"
19:26:17 <mtaylor> https://review.openstack.org/#settings,preferences  <-- and then what Kiall said
19:26:25 <notmyname> mtaylor: and the other thing is the status of the discussion on removing the default text for the votes (eg a -1 could/should only put in the comment "-1")
19:26:32 <mtaylor> adam_g: we'd start off triggering jobs post-merge I think
19:26:54 <mtaylor> adam_g: and we'd be interested in getting back _everything_ (verbose logs are great, because that way devs can diagnose)
19:27:46 <adam_g> mtaylor: we currently trigger a full deployment/test run on post-merge to nova. but build new packages for commits to almost everything else
19:27:55 <adam_g> mtaylor: i suppose you and i can sync up sometime outside of meeting to get the ball rolling on this
19:28:25 <annegentle> o/
19:28:32 <mtaylor> adam_g: totally! let's just say that I'm quite excited to get that working!
19:28:45 <mtaylor> notmyname: physically it's easy to change the text - it's a db table
19:29:01 <notmyname> mtaylor: if it can be done per project, can we get it changed for swift?
19:29:32 <mtaylor> notmyname: practically, the text needs to be something, because the -1/+1 doesn't get put into the set of comments, so you can't see vote history any way other than the comment text in the review comment history
19:29:54 <notmyname> make the text "-1" or "+1" or whatever
19:30:15 * LinuxJedi is sure there is a bug open for the default message somewhere...
19:30:15 <annegentle> I have 2 Qs - 1) if I use git review on Lion am I going to run into trouble? See https://bugs.launchpad.net/git-review/+bug/900317.
19:30:16 <uvirtbot> Launchpad bug 900317 in git-review "Upgrade doesn't seem to work on MacOSX 10.7.2 Lion" [High,Triaged]
19:30:17 <mtaylor> it _could_ be changed to be the string "-1" of course - but it's global to all of gerrit, so you'd need to get some consensus across everyone
19:31:17 <mtaylor> annegentle: gah. I keep meaning to try to find a Lion system to track that bug down ...
19:31:21 <notmyname> mtaylor: no worries if it's a global thing. if it were per project, it's something I'd want changed. not sure if it's really worth the effort to get it changed globally
19:31:23 <mtaylor> anybody here on OSX Lion?
19:31:27 <notmyname> me
19:31:40 <notmyname> (but only for editors, etc. dev target is a VPS)
19:31:46 <LinuxJedi> https://bugs.launchpad.net/openstack-ci/+bug/914431
19:31:48 <uvirtbot> Launchpad bug 914431 in openstack-ci "remove automatic comment text from reviews" [Low,Triaged]
19:32:00 <LinuxJedi> that is the one I am thinking
19:32:00 <mtaylor> great! are you using git-review and/or is it working for you?
19:32:06 <mtaylor> LinuxJedi: yes. that's the one
19:32:33 <annegentle> mtaylor: ok I'm just hoping it's not going to affect my work
19:32:46 <mtaylor> annegentle: I am also hoping that!
19:33:05 <LinuxJedi> annegentle: if you run into any problems feel free to ask for help
19:33:21 <mtaylor> annegentle: although that error looks like some sort of system issue with pip and not anything specifically git-review related
19:33:28 <mtaylor> annegentle: LinuxJedi can solve all problems
19:33:31 <annegentle> mtaylor: and my next question is a basic one - can I get some help patching an already submitted patch? I'm embarrassed I don't know how to already :)
19:33:34 <notmyname> mtaylor: yes. git-review is working fine for me. I'm using a local (ie current) version of git, and I had to change one of my config settings for ui color (but I don't think that's related to git-review
19:33:38 <LinuxJedi> lol! :)
19:33:42 <mtaylor> annegentle: yes - be happy to
19:34:00 <annegentle> mtaylor: yay thanks I'll PM you and not take up meeting time :)
19:34:45 <mtaylor> annegentle: ok. simple story is "git review -d 2354 # where 2354 is the gerrit review id ; # edit patch ; git commit -a --amend ; git review"
19:34:57 <mtaylor> annegentle: but grab me and we'll walk through it
19:35:53 <mtaylor> notmyname: hopefully color thing not related to git review - we did get a patch a while back to make it work properly if git was configured for color output
19:35:54 <annegentle> thanks!
19:36:12 <mtaylor> oh! while I'm bugging notmyname about things ...
19:36:35 <notmyname> mtaylor: ya, I had color.ui = True and the newer version of git needed color.ui = always. git-review was fine (I know, I looked at the source)
19:36:52 <mtaylor> we're currently doing virtualenv-based testing for everyone except for swift
19:37:09 <notmyname> do we still have some hard coded python paths?
19:37:19 <mtaylor> the new approach to which is using tox (as I babbled about before)
19:37:35 <notmyname> I was in here late and did catch all your babbling ;-)
19:37:42 <notmyname> didn't*
19:37:52 <mtaylor> notmyname: what? you're not always paying attention to me? weird...
19:38:15 <notmyname> oh it's in the scoll buffer somewhere...
19:38:51 <mtaylor> notmyname: main thing is that I'd like to add a tox.ini file to the swift tree (I don't have one written yet) to allow us to use it to do multi-python-version testing and venv-based testing without copying gobs of code into your tree
19:39:56 <notmyname> ah. you know my feelings on having meta stuff in the code (like vcs stuff, review stuff, now testing env stuff)
19:40:17 <mtaylor> notmyname: that's why I wanted to touch base with you about tha
19:40:21 <notmyname> :-)
19:41:05 <notmyname> I'm not familiar with tox, so if it's something that offers benefit outside of our specific testing environment, then I'll be more for it
19:41:10 <notmyname> (the tox.ini)
19:42:01 <mtaylor> notmyname: it's a tool that knows how to drive nose and friends and to do it in various per-version virtualenvs
19:42:18 <mtaylor> notmyname: might be easier to look at example ... python-quantumclient is set up to use tox
19:43:02 <notmyname> ok, let me look in to it and then ping me later about it
19:43:13 <mtaylor> notmyname: awesome. thanks
19:43:35 <mtaylor> notmyname: also, when you do look in to it, there are currently more stanzas in the quantumclient tox.ini than I really want to be in there
19:44:23 <mtaylor> notmyname: I'm working on a fix to upstream to allow me to fix that/collapse them
19:44:36 <mtaylor> ok. I think that's it for me... anything else?
19:44:49 <notmyname> mtaylor: status of your vcsversion stuff?
19:45:29 <mtaylor> notmyname: languishing - got a slammed the last couple of weeks - but I have nice plane flight tomorrow, which is normally where I get all of my hacking on that done :)
19:45:37 <notmyname> cool
19:45:38 <mtaylor> notmyname: I did get some good feedback from ttx though
19:45:42 <notmyname> great
19:45:46 <mtaylor> so I'm going to try to work through all of that
19:45:48 <notmyname> I'm still looking forward to it
19:45:51 <mtaylor> me too!
19:46:56 <LinuxJedi> notmyname: mtaylor is in the land of management now, so we will zap all his usual dev time ;)
19:47:08 <notmyname> eh
19:47:10 <notmyname> heh
19:48:08 <mtaylor> notmyname: yes. blame LinuxJedi's Home Based Worker Application Form Approvals
19:48:31 <LinuxJedi> oh wow that stuff is so much fun :)
19:49:05 <LinuxJedi> mtaylor: you could always fill in the "emigrate to USA" forms instead
19:49:28 <LinuxJedi> anyway, getting off-topic for the meeting :)
19:49:33 <mtaylor> indeed
19:49:39 <mtaylor> alright! I'm calling it
19:49:41 <mtaylor> #endmeeting