18:59:55 #startmeeting ci 18:59:56 Meeting started Tue Sep 25 18:59:55 2012 UTC. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:59:58 The meeting name has been set to 'ci' 19:00:16 last meeting: http://eavesdrop.openstack.org/meetings/ci/2012/ci.2012-09-18-19.07.html 19:00:26 seems like a CLA status update might be in order 19:00:33 yes 19:00:45 #topic gerrit/foundation CLA integration 19:00:48 fungi: go for it! 19:01:11 hi 19:01:11 the contributor agreement and contact information features of gerrit are fully operational to demo on review-dev.openstack.org 19:01:42 we're still waiting on the foundation to get us a contact information server 19:02:04 so for now, it posts to a dummy server i've got running elsewhere 19:02:34 fungi: the contact info server is just a collection point for user data? 19:02:39 and the foundation is likely going to want to make adjustments to the cla text itself (i ripped it from the wiki) 19:02:44 clarkb: yes 19:02:56 fungi: so basically just waiting on reed and jbryce at this point. 19:02:57 clarkb: mailing address, phone numbers 19:03:03 jeblair: correct 19:03:26 if you have an account on review-dev, you'll see your old signed cla is "expired" 19:03:50 you can sign a new one, and you can also submit "contact information" (which can be anything, even just a .) 19:04:06 clarkb: and the idea here is the foundation server will use the receipt of this information not only as a legal record, but to update db information on its side as to who's eligible to vote, etc. 19:04:19 jeblair: nice 19:04:52 any validation of said contact information must be performed post-decryption on the foundation side 19:05:28 also, if the foundation server returns anything other than a 200 OK (or fails to respond at all), gerrit will not record that the information was successfully submitted and the user will have to try again later 19:06:08 clarkb: so they can use that to ensure that your gerrit email addr matches one you've registered with the foundation, which will provide the positive link between the 2 dbs 19:06:17 once contact information is submitted and a cla "signed" (by typing I AGREE), then the user can submit commits to gerrit again 19:06:39 until then, they get one of a couple of error messages back on the ssh port when attempting write operations 19:07:01 either stating that their cla has expired and they must sign a new one, or that their signed cla requires submission of contact info 19:07:18 #action jbryce provide a test foundation server 19:07:31 so anyway, all of that is tested and working on review-dev now 19:07:32 is it possible to apply the CLA changes to review.o.o without enforcement (use LP sync until jbryce is ready)? 19:08:01 we could push everything except the db change 19:08:04 I guess we need to have patience this week regardless so that isnt a big deal 19:08:14 clarkb: what changes would those be? 19:08:35 jeblair: adding the CLA to review.o.o, applying the bug fixes, etc 19:08:47 the bug fixes are already applied 19:08:59 clarkb: i must be missing something; review.o.o has a cla.... 19:09:29 and the puppet infrastructure is in place, just missing a handful of lines in review.pp and hiera/site.pp 19:09:40 jeblair: I guess my question is better phrased as, "Is it safe to change the puppet manifest for openstack_project::gerrit.pp to be like review_dev.pp?" 19:10:11 clarkb: no, because we can't change the CLA process until the new foundation server is ready 19:10:16 k 19:10:58 clarkb: until then, echosign and ~openstack-cla is the existing process 19:11:38 anyway, that's all i have on cla/contacts unless there are questions 19:12:05 i have a couple other projects we can discuss, or table to -infra more informally 19:12:42 fungi: lets hit those at the end 19:12:46 #topic translations 19:13:02 clarkb: did you "solve django with GabrielHurley" ? :) 19:13:41 jeblair: no, GabrielHurley is a hard person to get a hold of. That may need to wait for the summit; however, I have been floating some ideas on how to solve this issue 19:14:09 First translation jobs for non django jobs appear to be working and are stabel 19:14:26 clarkb: do you want to propose a summit session for this topic? 19:14:36 clarkb: (yay!) 19:15:01 #link https://review.openstack.org/#/q/topic:transifex/translations+status:merged,n,z 19:15:24 jeblair: probably not a bad idea. 19:15:34 #action clarkb propose summit session for translations 19:15:56 yay! 19:16:14 clarkb: do you need me to poke Gabriel? 19:16:39 heckj: that would be great for a quick chat after this meeting 19:16:49 clarkb: I'll see if I can wrangle him up 19:17:25 I think Horizon translations can be handled as a special case of the existing jobs. The basics of what the job need to do don't change, just the commands to extract messages do 19:17:26 clarkb: http://summit.openstack.org/ 19:17:50 clarkb: that sounds reasonable under the circumstances. 19:18:15 eg the gerrit commands, git commands, and transifex commands are static 19:18:29 but I need to confirm with Gabriel that that is the case 19:19:41 #topic mordred 19:19:52 #action mtaylor is now known as mordred 19:19:59 just for the record. 19:20:22 and he did register the summit topics he said he would last week. :) 19:20:48 he also announced the inception of #link http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra 19:20:58 in case anyone missed it on -dev 19:21:14 #action everyone sign up for http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra 19:21:19 and we have our first e-mail, from david kranz, asking for help 19:21:31 yeah. please do that - there was a message I was going to send to that list -but then I realized nobody was on it yet 19:21:34 yay! 19:21:39 done 19:21:55 * jeblair just signed up 19:22:11 now if I could remember what I wanted to talk about ... 19:22:14 * fungi fears he was subscriber #2 19:22:51 #link http://lists.openstack.org/pipermail/openstack-infra/2012-September/000000.html 19:24:27 so, who else has a topic? fungi? (mordred, when ever you remember...) 19:25:26 jeblair: did we update jenkins between now and the last meeting? 19:25:32 time is all blended together 19:25:48 clarkb: i believe we did 19:25:54 #topic jenkins upgrade 19:26:11 JENKINS UPGRADE FAIL FAIL FAIL 19:26:18 with ttx's blessing, we unfroze the CI systems (they are in a soft freeze around release) 19:26:37 and upgraded jenkins to fix a (nasty) remote vulnerability 19:26:52 which uncovered the fact that jenkins is remarkably poorly tested befor release 19:27:05 s/poorly/not/ 19:27:14 and completely hosed us because someone committed a patch without realizing that jenkins has a json api 19:27:32 so, um, uncool. 19:27:46 anyway, we're now running a daily build in production to address that 19:28:07 thanks to lifeless who remembered that daily builds exist. 19:28:26 I think it is a release candidate build 19:29:15 yeah, i think they build everything on the rc branch, or something like that. it was 3am at the time, i don't remember all the details. 19:29:26 jeblair: you could also have compiled your own. 19:29:29 Or not. 19:29:51 as a result of that I think we lost four precise slaves 19:29:55 ttx: yeah, an option we considered, but we would have had to actually do that, and we kinda needed it fixed "right now" 19:30:20 jeblair: it's not really fun or easy 19:30:21 precise6,9,10,14 are all not accepting ssh connections 19:30:41 ttx: as opposed to "when one of us gets a dev box with all the right java bits installed and figures out how to build it". 19:31:05 clarkb: did mordred (or mtaylor) ever get around to kicking those for you? 19:31:25 jeblair: mtaylor was supposed to 19:31:32 jeblair: but I haven't seen him in a while 19:32:00 #action corvus to ask mordred to have mtaylor kick slaves 19:32:15 DIE DIE DIE 19:32:42 why the nick change anyways? 19:33:00 availability 19:33:15 I've been mordred everywhere else since around 93 19:33:24 just because 19:33:27 but some other guy had it on here 19:33:39 so, other jenkins problems... 19:34:06 it looks like even thought we removed all the stuff that should have been causing jenkins to enforce builds finish in order (which we don't care about).... 19:34:11 it still does it anyway 19:34:55 (removing things like the junit results was, according to bug reports, supposed to address that) 19:35:05 that could be a new "feature" added by our recent upgrade 19:36:02 at any rate, it seems that occasionally jenkins can still get stuck after the build has succeeded or failed, but before it's really finished 19:36:16 in that case, i don't _believe_ the timeout plugin will help us 19:36:38 that merits testing, and if it's the case, perhaps we should have zuul time out and abort jenkins builds 19:37:06 (or implement a robotic "ttx") 19:37:29 any thoughts 19:37:30 ? 19:38:51 #topic puppet 19:39:25 pabelanger has been kicking puppet into shape, by removing our weird modules and replacing them with real modules (either ours, or someone else's (like his)) 19:39:33 which is great 19:40:39 Yup, infact almost finished with the gate-ci-puppet-lint 19:41:00 #action pabelanger add gate-ci-puppet-lint job 19:41:01 however, it will fail pretty hard until puppet-lint passes 19:41:24 cool, well even while it's non-voting, we can check the output on changes 19:42:07 #topic global bacon shortage 19:42:11 #link http://www.huffingtonpost.com/2012/09/24/bacon-sausage-shortage_n_1909609.html 19:42:16 oh no. 19:42:35 fungi: i'm pretty sure you said you had more topics? :) 19:42:37 jeblair: we have had more changes submitted for zuul 19:42:45 I think wikimedia is attempting to use it so yay 19:42:48 #topic zuul 19:42:57 yes, zuul has sprouted contributors! 19:43:16 yeah, i have planning questions on two new projects (managing jenkins global config, and symbolic-ref entries to map release names to git branches) but i can save those for #o-infra or the ml unless anyone finds them exciting 19:43:22 i think the new -ifra list will be a good place for other ppl to talk about zuul, job builder etc... 19:43:40 agreed, three cheers for the ml 19:44:19 and i think after the current freeze, we may need to run those projects more like real projects -- discuss/announce big changes, migrations, etc... and maybe not freeze trunk because of openstack's schedule. 19:44:29 (which may mean our running zuul not from trunk) 19:44:53 #topic jenkins global config 19:44:58 fungi: whatcha got? 19:45:25 well, looks like there is an almost-sane feature in jenkins to reload its configuration on the fly 19:45:44 it has a bug, currently, wherein it forgets about any running jobs 19:45:49 ha 19:45:55 there are some workarounds and one proposed patch in their bug tracker 19:46:16 fungi: i dunno, sounds like we can use that to fix our other problem! ;) 19:46:35 fungi: link to bug? 19:46:37 so a configuration merge script fed from puppet, with that fixed, might make configuration on-disk manageable 19:46:45 yeah, pulling it now--just a sec 19:47:04 #link https://issues.jenkins-ci.org/browse/JENKINS-3265 19:48:13 with that solved, i think a merge script to a new fd, move the old config out of the way and rename the new one into place, api call to reload... 19:48:46 then re-merge against the old config again and make sure it still produces the same new config (to check for any possible race where jenkins tried to update it in the interim) 19:49:23 I am going to but in but apevec in -dev says the cert on review.o.o is verified by an agency that FF no longer trusts 19:49:32 i went down the api route first, but its global configuration via webui uses totally different code not backed by its api 19:50:14 clarkb: ack 19:50:16 (the jenkins api seems to be an afterthought, added to ease management of individual job configs) 19:50:21 fungi: yeesh. 19:50:34 :( 19:50:52 fungi: so i don't think this is important enough to, eg, build our own jenkins to solve it... 19:51:04 fungi: but maybe keep an eye on that, and when it's fixed, take another look? 19:51:16 jeblair: i agree 19:51:29 #topic symbolic-ref 19:52:09 #link https://bugs.launchpad.net/openstack-ci/+bug/995604 19:52:10 Launchpad bug 995604 in openstack-ci "use symbolic-ref from gerrit to provide moving codename targets" [High,In progress] 19:52:21 yay bot 19:52:33 * koolhead17 waves 19:52:56 i added several branches to a project on my test gerrit and then added symbolic-ref entries for them 19:53:07 seems to work just fine from a gerrit perspective 19:53:38 however, symbolic-ref is a local concept, and won't get automatically replicated to github or anything (if that was the intent) 19:53:51 fungi: is there any way to force replication? 19:54:19 (it was the intent, so i think replication to github is a requirement 19:54:25 clarkb: none that i could find. github added a button on their webui to skin it 19:54:46 you can't push a symbolic-ref to a git server, for example 19:54:55 also, even if we do replicate to github... if it's not automatic or easy to get in clones, it may be less useful... 19:55:12 you can push to a symbolic-ref which the server takes as a means of pushing to the branch to which it refers 19:55:26 instructions that say "run 'git checkout folsom'" that don't always work would be bad... 19:55:44 and you can clone from it, but you wind up with a local branch named whatever the symbolic-ref's name was 19:56:24 which may be enough 19:57:11 i think one of the main use cases was for intra-project dependencies, so someone could pip-require a git repo with a pointer to folsom... 19:57:20 but i think that's largely handled by tarballs.... 19:57:24 so.... 19:57:37 #action mordred document use cases for bug 995604 19:57:37 Launchpad bug 995604 in openstack-ci "use symbolic-ref from gerrit to provide moving codename targets" [High,In progress] https://launchpad.net/bugs/995604 19:57:56 i can summarize my findings more eloquently in an update to the lp bug 19:58:01 fungi: then we'll know how to procede. :) 19:58:03 fungi: cool 19:58:16 that's it for me 19:58:22 eloquence ftw (he says ironically) 19:58:29 thanks everyone! 19:58:32 #endmeeting