18:59:55 <jeblair> #startmeeting ci
18:59:56 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:59:58 <openstack> The meeting name has been set to 'ci'
19:00:16 <jeblair> last meeting: http://eavesdrop.openstack.org/meetings/ci/2012/ci.2012-09-18-19.07.html
19:00:26 <jeblair> seems like a CLA status update might be in order
19:00:33 <fungi> yes
19:00:45 <jeblair> #topic gerrit/foundation CLA integration
19:00:48 <jeblair> fungi: go for it!
19:01:11 <pabelanger> hi
19:01:11 <fungi> the contributor agreement and contact information features of gerrit are fully operational to demo on review-dev.openstack.org
19:01:42 <fungi> we're still waiting on the foundation to get us a contact information server
19:02:04 <fungi> so for now, it posts to a dummy server i've got running elsewhere
19:02:34 <clarkb> fungi: the contact info server is just a collection point for user data?
19:02:39 <fungi> 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 <fungi> clarkb: yes
19:02:56 <jeblair> fungi: so basically just waiting on reed and jbryce at this point.
19:02:57 <fungi> clarkb: mailing address, phone numbers
19:03:03 <fungi> jeblair: correct
19:03:26 <fungi> if you have an account on review-dev, you'll see your old signed cla is "expired"
19:03:50 <fungi> you can sign a new one, and you can also submit "contact information" (which can be anything, even just a .)
19:04:06 <jeblair> 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 <clarkb> jeblair: nice
19:04:52 <fungi> any validation of said contact information must be performed post-decryption on the foundation side
19:05:28 <fungi> 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 <jeblair> 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 <fungi> 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 <fungi> until then, they get one of a couple of error messages back on the ssh port when attempting write operations
19:07:01 <fungi> 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 <jeblair> #action jbryce provide a test foundation server
19:07:31 <fungi> so anyway, all of that is tested and working on review-dev now
19:07:32 <clarkb> is it possible to apply the CLA changes to review.o.o without enforcement (use LP sync until jbryce is ready)?
19:08:01 <fungi> we could push everything except the db change
19:08:04 <clarkb> I guess we need to have patience this week regardless so that isnt a big deal
19:08:14 <jeblair> clarkb: what changes would those be?
19:08:35 <clarkb> jeblair: adding the CLA to review.o.o, applying the bug fixes, etc
19:08:47 <fungi> the bug fixes are already applied
19:08:59 <jeblair> clarkb: i must be missing something; review.o.o has a cla....
19:09:29 <fungi> and the puppet infrastructure is in place, just missing a handful of lines in review.pp and hiera/site.pp
19:09:40 <clarkb> 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 <jeblair> clarkb: no, because we can't change the CLA process until the new foundation server is ready
19:10:16 <clarkb> k
19:10:58 <jeblair> clarkb: until then, echosign and ~openstack-cla is the existing process
19:11:38 <fungi> anyway, that's all i have on cla/contacts unless there are questions
19:12:05 <fungi> i have a couple other projects we can discuss, or table to -infra more informally
19:12:42 <jeblair> fungi: lets hit those at the end
19:12:46 <jeblair> #topic translations
19:13:02 <jeblair> clarkb: did you "solve django with GabrielHurley" ? :)
19:13:41 <clarkb> 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 <clarkb> First translation jobs for non django jobs appear to be working and are stabel
19:14:26 <jeblair> clarkb: do you want to propose a summit session for this topic?
19:14:36 <jeblair> clarkb: (yay!)
19:15:01 <clarkb> #link https://review.openstack.org/#/q/topic:transifex/translations+status:merged,n,z
19:15:24 <clarkb> jeblair: probably not a bad idea.
19:15:34 <clarkb> #action clarkb propose summit session for translations
19:15:56 <heckj> yay!
19:16:14 <heckj> clarkb: do you need me to poke Gabriel?
19:16:39 <clarkb> heckj: that would be great for a quick chat after this meeting
19:16:49 <heckj> clarkb: I'll see if I can wrangle him up
19:17:25 <clarkb> 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 <jeblair> clarkb: http://summit.openstack.org/
19:17:50 <jeblair> clarkb: that sounds reasonable under the circumstances.
19:18:15 <clarkb> eg the gerrit commands, git commands, and transifex commands are static
19:18:29 <clarkb> but I need to confirm with Gabriel that that is the case
19:19:41 <jeblair> #topic mordred
19:19:52 <jeblair> #action mtaylor is now known as mordred
19:19:59 <jeblair> just for the record.
19:20:22 <jeblair> and he did register the summit topics he said he would last week.  :)
19:20:48 <fungi> he also announced the inception of #link http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
19:20:58 <fungi> in case anyone missed it on -dev
19:21:14 <jeblair> #action everyone sign up for http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
19:21:19 <fungi> and we have our first e-mail, from david kranz, asking for help
19:21:31 <mordred> 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 <mordred> yay!
19:21:39 <pabelanger> done
19:21:55 * jeblair just signed up
19:22:11 <mordred> now if I could remember what I wanted to talk about ...
19:22:14 * fungi fears he was subscriber #2
19:22:51 <jeblair> #link http://lists.openstack.org/pipermail/openstack-infra/2012-September/000000.html
19:24:27 <jeblair> so, who else has a topic?  fungi?  (mordred, when ever you remember...)
19:25:26 <clarkb> jeblair: did we update jenkins between now and the last meeting?
19:25:32 <clarkb> time is all blended together
19:25:48 <jeblair> clarkb: i believe we did
19:25:54 <jeblair> #topic jenkins upgrade
19:26:11 <mordred> JENKINS UPGRADE FAIL FAIL FAIL
19:26:18 <jeblair> with ttx's blessing, we unfroze the CI systems (they are in a soft freeze around release)
19:26:37 <jeblair> and upgraded jenkins to fix a (nasty) remote vulnerability
19:26:52 <jeblair> which uncovered the fact that jenkins is remarkably poorly tested befor release
19:27:05 <mordred> s/poorly/not/
19:27:14 <jeblair> and completely hosed us because someone committed a patch without realizing that jenkins has a json api
19:27:32 <jeblair> so, um, uncool.
19:27:46 <jeblair> anyway, we're now running a daily build in production to address that
19:28:07 <jeblair> thanks to lifeless who remembered that daily builds exist.
19:28:26 <clarkb> I think it is a release candidate build
19:29:15 <jeblair> 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 <ttx> jeblair: you could also have compiled your own.
19:29:29 <ttx> Or not.
19:29:51 <clarkb> as a result of that I think we lost four precise slaves
19:29:55 <jeblair> 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 <ttx> jeblair: it's not really fun or easy
19:30:21 <clarkb> precise6,9,10,14 are all not accepting ssh connections
19:30:41 <jeblair> 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 <jeblair> clarkb: did mordred (or mtaylor) ever get around to kicking those for you?
19:31:25 <mordred> jeblair: mtaylor was supposed to
19:31:32 <mordred> jeblair: but I haven't seen him in a while
19:32:00 <jeblair> #action corvus to ask mordred to have mtaylor kick slaves
19:32:15 <mtaylor> DIE DIE DIE
19:32:42 <pabelanger> why the nick change anyways?
19:33:00 <mordred> availability
19:33:15 <mordred> I've been mordred everywhere else since around 93
19:33:24 <mtaylor> just because
19:33:27 <mordred> but some other guy had it on here
19:33:39 <jeblair> so, other jenkins problems...
19:34:06 <jeblair> 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 <jeblair> it still does it anyway
19:34:55 <jeblair> (removing things like the junit results was, according to bug reports, supposed to address that)
19:35:05 <jeblair> that could be a new "feature" added by our recent upgrade
19:36:02 <jeblair> 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 <jeblair> in that case, i don't _believe_ the timeout plugin will help us
19:36:38 <jeblair> that merits testing, and if it's the case, perhaps we should have zuul time out and abort jenkins builds
19:37:06 <jeblair> (or implement a robotic "ttx")
19:37:29 <jeblair> any thoughts
19:37:30 <jeblair> ?
19:38:51 <jeblair> #topic puppet
19:39:25 <jeblair> 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 <jeblair> which is great
19:40:39 <pabelanger> Yup, infact almost finished with the gate-ci-puppet-lint
19:41:00 <jeblair> #action pabelanger add gate-ci-puppet-lint job
19:41:01 <pabelanger> however, it will fail pretty hard until puppet-lint passes
19:41:24 <jeblair> cool, well even while it's non-voting, we can check the output on changes
19:42:07 <jeblair> #topic global bacon shortage
19:42:11 <jeblair> #link http://www.huffingtonpost.com/2012/09/24/bacon-sausage-shortage_n_1909609.html
19:42:16 <clarkb> oh no.
19:42:35 <jeblair> fungi: i'm pretty sure you said you had more topics?  :)
19:42:37 <clarkb> jeblair: we have had more changes submitted for zuul
19:42:45 <clarkb> I think wikimedia is attempting to use it so yay
19:42:48 <jeblair> #topic zuul
19:42:57 <jeblair> yes, zuul has sprouted contributors!
19:43:16 <fungi> 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 <jeblair> i think the new -ifra list will be a good place for other ppl to talk about zuul, job builder etc...
19:43:40 <fungi> agreed, three cheers for the ml
19:44:19 <jeblair> 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 <jeblair> (which may mean our running zuul not from trunk)
19:44:53 <jeblair> #topic jenkins global config
19:44:58 <jeblair> fungi: whatcha got?
19:45:25 <fungi> well, looks like there is an almost-sane feature in jenkins to reload its configuration on the fly
19:45:44 <fungi> it has a bug, currently, wherein it forgets about any running jobs
19:45:49 <clarkb> ha
19:45:55 <fungi> there are some workarounds and one proposed patch in their bug tracker
19:46:16 <jeblair> fungi: i dunno, sounds like we can use that to fix our other problem! ;)
19:46:35 <jeblair> fungi: link to bug?
19:46:37 <fungi> so a configuration merge script fed from puppet, with that fixed, might make configuration on-disk manageable
19:46:45 <fungi> yeah, pulling it now--just a sec
19:47:04 <fungi> #link https://issues.jenkins-ci.org/browse/JENKINS-3265
19:48:13 <fungi> 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 <fungi> 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 <clarkb> 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 <fungi> 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 <jeblair> clarkb: ack
19:50:16 <fungi> (the jenkins api seems to be an afterthought, added to ease management of individual job configs)
19:50:21 <jeblair> fungi: yeesh.
19:50:34 <clarkb> :(
19:50:52 <jeblair> fungi: so i don't think this is important enough to, eg, build our own jenkins to solve it...
19:51:04 <jeblair> fungi: but maybe keep an eye on that, and when it's fixed, take another look?
19:51:16 <fungi> jeblair: i agree
19:51:29 <jeblair> #topic symbolic-ref
19:52:09 <fungi> #link https://bugs.launchpad.net/openstack-ci/+bug/995604
19:52:10 <uvirtbot> Launchpad bug 995604 in openstack-ci "use symbolic-ref from gerrit to provide moving codename targets" [High,In progress]
19:52:21 <fungi> yay bot
19:52:33 * koolhead17 waves
19:52:56 <fungi> i added several branches to a project on my test gerrit and then added symbolic-ref entries for them
19:53:07 <fungi> seems to work just fine from a gerrit perspective
19:53:38 <fungi> 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 <clarkb> fungi: is there any way to force replication?
19:54:19 <jeblair> (it was the intent, so i think replication to github is a requirement
19:54:25 <fungi> clarkb: none that i could find. github added a button on their webui to skin it
19:54:46 <fungi> you can't push a symbolic-ref to a git server, for example
19:54:55 <jeblair> 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 <fungi> 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 <jeblair> instructions that say "run 'git checkout folsom'" that don't always work would be bad...
19:55:44 <fungi> 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 <fungi> which may be enough
19:57:11 <jeblair> 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 <jeblair> but i think that's largely handled by tarballs....
19:57:24 <jeblair> so....
19:57:37 <jeblair> #action mordred document use cases for bug 995604
19:57:37 <uvirtbot> 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 <fungi> i can summarize my findings more eloquently in an update to the lp bug
19:58:01 <jeblair> fungi: then we'll know how to procede.  :)
19:58:03 <jeblair> fungi: cool
19:58:16 <fungi> that's it for me
19:58:22 <jeblair> eloquence ftw (he says ironically)
19:58:29 <jeblair> thanks everyone!
19:58:32 <jeblair> #endmeeting