19:02:59 #startmeeting CI 19:03:00 Meeting started Tue Sep 11 19:02:59 2012 UTC. The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:02 The meeting name has been set to 'ci' 19:03:27 jeblair: around? 19:03:35 o/ 19:04:08 clarkb: and i were deep in conversation 19:04:10 whee! 19:04:56 so - anybody do anything this past week that's interesting? 19:05:01 jeblair: ? 19:05:23 mtaylor: perhaps! let me get my ducks in a row. 19:05:33 neat. while he's ordering ducks... 19:05:39 fungi: how things been going? 19:05:52 the gerrit trivial rebase hook went in 19:06:01 woot 19:06:06 there was a brief discussion on the -dev ml 19:06:14 silly whitespace 19:06:22 git-patch-id is a bit biased in favor of c, yes 19:06:35 we'd like to fix that with a cli option 19:06:58 i can see it being generally useful for whitespace-significant languages 19:07:16 in the meantime, working on the gerrit cla implementation 19:07:56 i confirmed the .war rebuilt without the cla bits hacked out works the same as upstream's so we should be good there 19:08:29 i've got all the info i need to turn on that piece confirmed/tested, but now i'm working through the contact store feature 19:08:35 fungi: it is worth mentioning that the build is non deterministic and sometimes the generated javascript doesn't work in all browsers 19:08:52 tl;dr make sure you test the web gui with firefox and chrom* 19:08:53 * mtaylor salutes java! 19:09:13 clarkb: nice! okay, time to install some chrome (already tested in iceweasel/ff) 19:09:21 when it fails, it usually fails obviously and immediately if you view a change 19:09:35 jeblair: good to know 19:09:42 i'll test for that too 19:09:42 * mtaylor sticks head into dangerous territory... 19:10:02 do we know enough about whatchacallit now to build a test for that? or should I butt out? 19:10:13 selenium? 19:10:16 yeah 19:10:26 mtaylor: we can actually test it by inspecting the war 19:10:32 mtaylor: there are some 0 byte files we can look for 19:10:36 lovely 19:10:44 brb 19:10:49 manual inspection is probably fine too I'm guessing 19:11:05 anyway, that's all the updates i had so far 19:11:15 excellent. nicely done 19:11:20 jeblair: how are your ducks? 19:11:44 arrayed! 19:12:29 i've reconfigured jenkins to reduce build history now that the logs are copied to logs.o.o 19:13:09 so that's one of the first results from all that recent work that we expect to have an actual impact on some jenkins load 19:13:19 (but there's still more coming) 19:13:35 we now fail tox unit test runs if they attempt to use sudo 19:13:48 i've made some general improvements to jenknis job builder project (it's an independent project, but still lacks some niceties like docs, a readme, tests, and can use some more cleanup work) 19:14:05 (and there's a new contributor from HP, yay!) 19:14:43 and i'm testing a gerrit-git-prep script that uses zuul references, when that's merged, we can remove some older GERRIT_ variables from zuul, and then we should be able to tell zuul to cherry-pick openstack-ci-puppet, which should hopefully fix the cherry-pick related problems we had there 19:15:15 that's about it, i think 19:15:32 on the topic of jenkins efficiency improvements... 19:15:52 there was a suggestion in -infra during the wee hours of yesterday morning 19:16:05 can't remember the nick... i'd need to check my scrollback 19:16:39 but basically, asking it if would make sense to dequeue or cancel jenkins tests when a new patchset gets uploaded, if they haven't started/completed yet on the previous one 19:16:47 oh yeah, I remember that 19:16:52 I thought we were already doing that? 19:17:11 I don't think we are check tests run in an independent queue 19:17:15 so they are truly independent 19:17:21 ah 19:17:40 fungi: yes, that would be a good idea. i think it was on our "improve zuul efficiency" list from a little while back... 19:17:48 but it's not a huge deal... 19:18:17 the implementation should actually handle both check and gate queues 19:18:49 (as in, it should dequeue the change immediately from the gate queue) 19:19:16 sounds ideal 19:19:27 some of the recent work i did refactoring zuul's queing should make it a little easier to implement, actually. 19:19:59 anyway, i won't be getting to that right away, so if anyone else feels like hacking that, consider it open. :) 19:20:42 cool. good stuff - that's it for you, yeah? 19:20:52 t 19:21:13 clarkb: you do anything last week? 19:21:46 some stuff. The biggest and most exciting thing happened recently (yesterday). I resurrected the transifex translation jobs for nova 19:21:50 WOOHOO 19:22:30 the job that pushes updates to transifex is not quite working yet. The jenkins transifex user needs to be able to push updated .pot files to transifex 19:22:37 so close! 19:23:02 and the job that adds translation changes to gerrit hasn't run yet. It is set to @daily. DOes jenkins run those at 0:00UTC? 19:23:13 clarkb: i think so 19:23:27 it runs them at $time 19:23:40 so that should happen within the next 24 hours 19:23:46 mtaylor: $time? 19:24:21 * mtaylor should stop saying stupid things 19:24:55 I recently noticed the jclouds setup on jenkins-dev stopped working so I got that mostly going again. rackspace cloud still hates me though. 19:25:38 if I can get rackspace sorted out the only addition concern is load balancing the creating of servers. Jclouds by default seems to use your first provider until ti runs out of nodes then it switches to the second provider 19:26:14 :/ 19:26:31 definitely less than ideal. 19:26:41 even a simple round-robin would be better 19:27:12 yeah. round robin would be much better 19:27:15 as would better logging 19:27:56 mtaylor: speaking of you drawing people's attention to things... 19:28:12 mtaylor: you were given an action item last week; you may not have seen it: http://eavesdrop.openstack.org/meetings/ci/2012/ci.2012-09-04-19.02.html 19:28:13 On Friday zuul decided that it would stop talking to nova. the ref at the tip of master was packed, but zuul's repo object for the nova repo did not know how to use pack files 19:28:26 aha! 19:28:29 * mtaylor will do that 19:28:43 mtaylor: I need to update the pull request too 19:28:55 clarkb: oh yeah, i apparently didn't commit that to long term memory due to airline related brain disfunction. 19:29:24 clarkb: tell me when the pull request is ready for nagging 19:29:45 the fix for zuul is to not cache repo objects because GitPython only inspects the objects dir when you instantiate objects 19:29:50 jeblair merged the fix today 19:30:07 mtaylor: will do 19:30:11 clarkb: i think that's ultimately a gitpython bug... it seems like if you use gitpython to update a remote repo, it should know if it needs to recache/add new database types... 19:30:21 jeblair: agree 19:30:53 clarkb: you want to file that bug, or shall i? 19:31:14 jeblair: I think you did a lot more testing than I did so can probably articulate it better 19:31:25 drat 19:31:58 clarkb: but you did a great job on the investigation and analysis -- not to mention, the actual solution. :) 19:32:12 jeblair: ok I will file the bug :) 19:32:21 #action clarkb to file GitPython bug 19:33:01 I updated jenkins job builder to support property/variable injection. The doc jobs use this feature so this should enable us to switch those jobs to the job builder 19:33:13 excellent 19:33:19 I keep forgetting we have jobs that aren't using job builder 19:33:32 we should be able to pull those in now. 19:33:56 and the last thing I can remember is I got rid of the hardcoded sysadmins variable in puppet because email from razor is not so good 19:34:12 instead puppet now expects those values to be passed in from hiera at the site.pp level 19:34:14 i think we have everything (?) we need now for them in job builder 19:34:22 clarkb: thank goodness 19:34:27 clarkb: ++ 19:35:12 actually, jobs that don't use job builder may fail if we merge the gerrit-git-prep change (because job builder won't have switched them to zuul, they may be using gerrit trigger plugin) 19:35:48 (on the plus side, we'd find out which ones they are) 19:36:15 we may want to suss those out before merging that change. 19:38:03 ++ 19:39:23 well, from my side 19:39:29 I accomplished not breaking anything 19:39:35 and I also got back from burning man 19:39:39 so that's about it for me :) 19:39:56 your car doesn't count as broken? 19:40:06 mtaylor: did you ever hear back abotu your git scm change for jenkins? 19:40:17 mtaylor: the one that makes the git scm module clean the repo like we do? 19:40:28 fungi: well, _I_ didn't actually break my car ... that was Ishtar 19:40:38 jeblair: nope 19:40:46 jeblair: I will follow up on that one when I follow up on the scp one 19:41:31 clarkb: the #action verb should create a bug in launchpad and assign it to the person ... 19:42:00 it should 19:42:02 not a bad idea. 19:42:30 * mtaylor has to occasionally have good ideas 19:42:41 what's meetbot written in? (or i can just go look in git) 19:42:43 can we do lookups using irc nicks as keys in lo? 19:42:45 *lp 19:42:48 of course, knowing the project and the IRC-nick mapping will be a little bit ork 19:43:03 clarkb: well, lp users have irc nick fields 19:43:04 fungi: python, openstack-ci/meetbot 19:43:04 fungi: it is a supybot plugin written in python 19:43:05 lp has a field for irc nick 19:43:17 lifeless: any idea if there's a good way to get from an IRC nick to a Launchpad User ? 19:43:21 no idea if it can be queried from their api tho 19:43:45 whats the irc nick ? 19:43:54 lifeless: a variable. :) 19:44:26 I need one to test with 19:44:39 clarkb should be lp user cboylan 19:44:45 *clarkb@freenode 19:44:48 i've set my irc nick as fungi in my lp profile 19:45:02 https://launchpad.net/+search?field.text=clarkb 19:45:04 third row 19:45:18 We should be able to add an API lookup really easily. 19:45:24 File a bug? 19:46:09 lifeless: this is in context of an earlier statement of "the #action verb for meetbot should file a bug and assign it to a user" 19:46:17 clarkb: oh, you know what - the form is: 19:46:26 "#action username the action" 19:46:34 ahh, i see it displays in lp as "fungi on irc.freenode.net" so we may need to do some fuzzy matching on the network 19:46:36 so we could just make that take the launchpad id as the argument 19:46:37 mtaylor: that would work too 19:46:57 that won't be quite as intuitive... 19:47:05 adding an API lookup would be a very small amount of code. 19:47:09 file a bug :) 19:47:23 mtaylor: "#action jeblair do something" i mean "#action corvus do something" 19:47:49 #action clarkb file a bug 19:47:52 hehe 19:48:03 how meta 19:49:46 cool. and with that ... I think I'm done 19:49:48 anybody else? 19:50:06 nothing here 19:50:17 I will be out tomorrow, other than that i have nothing 19:50:24 nada 19:51:57 #action mtaylor to end meeting 19:52:41 #endmeeting