19:02:00 #startmeeting 19:02:01 Meeting started Tue Jul 10 19:02:00 2012 UTC. The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:35 first order of business ... hey jaypipes, anytihng new with tempest this week? 19:03:21 mtaylor: you're kiddin, right? :) 19:04:02 pretty sure something notable happened regarding tempest... 19:04:05 jaypipes: I'm not! it was a leading question 19:04:40 i'm ecstatic. it's something we've wanted to do since the essex design summit! 19:05:19 mtaylor: what jeblair said :) 19:05:29 mtaylor: we are now gating core projects on the tempest smoke tests. 19:05:49 jaypipes: so what do we need to do before we can stop running exercise.sh? 19:05:55 mtaylor: in addition, the full tempest test suite (minus smoke, but after successful completion of smoke) are being run for tempest merges 19:06:02 jaypipes: w00t! 19:06:07 jaypipes: that's super exciting! 19:06:08 jeblair: I just need to do the analysis gap coverage 19:06:20 jeblair: put a bug in on openstack-ci and assign to me? 19:06:27 jaypipes: will do! 19:07:06 jaypipes: just keep in mind devstack-gate isn't running all the exercise scripts, so it may not be that bad. 19:07:39 jeblair: k. everything but boot from volume, right? 19:07:44 It's worth noting that getting tempest trunk to pass against stable/essex is just a few small patches away. I got it working today, and will propose patches tomorrow. 19:08:02 So we should be able to use the same gate there. 19:08:16 soren: oh good, those are going to come in handy real soon i bet. :) 19:08:31 nice 19:08:44 right now the config is the same for all branches, but we can modify that if needed before your patches land (but hopefully that won't be necessary) 19:09:24 Dunno. I've only tested it with one configuration, so maybe. 19:09:50 * mtaylor does a little dance 19:10:04 ...but I can expand that for sure now. I just needed the ball to be green so that I could block stuff from getting in if it went red. 19:10:46 Anyway, carry on. 19:11:13 I think that's it on that one. 19:11:23 jeblair: you had something to do with that one, anything else interesting from you? 19:11:23 on a related note... 19:11:45 i'm working on adding more flexibility to zuul regarding which jobs are run and how... 19:12:17 so hopefully we can have a sane way of expressing that devstack-gate jobs for stable/diablo should run on oneiric slaves 19:12:35 (regardless of how much longer that's going to be relevant, i'm pretty sure it's going to be useful in the future too) 19:13:55 yup 19:13:57 agree 19:14:24 speaking of zuul - clarkb, did you add a feature people might care about this week? 19:14:59 there were some minor tweaks to the status page and you can now retrigger jobs by leaving comments on changes 19:15:18 a comment of "recheck" retriggers check jobs and a comment of "reverify" retriggers gate jobs 19:16:06 clarkb: if I say "reverify" 10 times straight on one review will zuul poo itself? 19:16:12 potentially 19:16:19 awesome :) 19:16:42 yeah, adding 'skip enqueuing a second build set for the same change' is a todo. :) 19:17:09 what does zuul poo look like? 19:17:34 * LinuxJedi python exceptions I guess 19:17:50 a big jenkins backlog. 19:18:00 * LinuxJedi doesn't know why I did /me there 19:18:00 heh. you said log 19:18:09 ANYWAY 19:18:09 better than drizzledump 19:18:26 LinuxJedi: what's the status of stackforge? 19:18:27 hey, i'm eating here. 19:18:38 well, we had lots of fun last week... 19:18:50 a bug in HP Cloud completely blew away Stackforge Jenkins 19:19:09 so we had 2 options: 1. rebuild, 2. go with the migration plan we talked about a couple of weeks ago 19:19:33 for those not following along at home the migration plan was to move gerrit and jenkins into Openstack's gerrit and jenkins 19:19:43 but keep github stuff separate 19:20:09 the US was out celebrating the fact they kicked us out 19:20:18 yay us! 19:20:22 woohoo! 19:20:24 so I made the decision to do option 2 19:20:27 stinky british people 19:20:33 lol :) 19:20:46 and the migration went pretty smoothly considering 19:21:04 so Stackforge now uses review.openstack.org and jenkins.openstack.org 19:21:20 and that is about it 19:21:49 oh, we now have no persistent servers on HP Cloud 19:22:04 * LinuxJedi destroyed what was left of Stackforge on HP Cloud on Friday 19:22:21 Where are they instaed? 19:22:29 Rackspace? 19:22:35 Just curious. 19:22:39 soren: we're just using the openstack ones 19:22:43 soren: which are all at rackspace 19:22:44 soren: they are part of Openstack's gerrit and jenkins, so yes 19:22:49 Ok. 19:23:35 on a positive note that gives us another tenant in HP Cloud to do evil things with 19:23:41 bwahahahaha 19:23:53 * LinuxJedi is thinking using CentOS 3 to fail everyone's code 19:24:27 * mtaylor decides to use all of the compute resources in that tennant to set up a giant distcc cluster... 19:24:44 devananda's openvz devstack stuff will apparently do evil things 19:24:51 mtaylor: that is an unlimited tenant, so knock yourself out ;) 19:24:58 LinuxJedi: BALLER 19:25:12 oh, we should get openstackjenkins to be unlimited... 19:25:21 yeah - how do we do that? 19:25:36 jeblair: ok, I assumed they were all unlimited, because I didn't hit a limit when I did crazy stuff 19:25:41 jeblair: also, I just sent you email, but we have blockstorage enabled now on that hpcloud tenant 19:26:08 oh, i think devstack-launch hits a quota sometimes. 19:26:23 mtaylor: that's great, i should be able to finish backups soon then! 19:26:26 so - for those following along at home, we're going to use hp's block-storage-as-a-service thing to get a persistent volume for backups 19:26:31 jeblair: w0t! 19:26:32 damn, they aren't unlimited then, that broke my world a bit 19:28:15 hrm. in other news, I've been working on landing some patches to get the version code applied to the server projects as well as the clients 19:28:31 and am continuing to work on an openstack-requires repo 19:29:03 for those who haven't looked at it - we have some REALLY interesting discrepancies between what we install in venvs for unittests and what devstack installs on the system via apt 19:29:37 more dramatic then different versions? 19:30:30 well, no - just different versions 19:30:48 damn, I was hoping for a 'Dallas' kind of drama 19:30:49 but it's interesting to see VERY specific version pins in pip-requires that are not what we install for devstack :) 19:31:50 devananda: how's openvz coming along? 19:32:06 we got the nova driver code from rackspace last week 19:32:27 so i spent several days figuring out how to get it to work with our ubuntu kernel 19:32:28 devananda now has square eyes reading through it all 19:32:34 and it does :) 19:32:54 on my bare metal box at home, i've got a working devstack with oepnvz containers and bridged networking 19:33:03 yay 19:33:48 one or two issues to work out with the networking, and i should be able to start running tests on it 19:34:26 excellent. which means we can then start actually get a jenkins stood up to do that regularly 19:34:38 indeed 19:34:56 on a similar track, spoke with primeministerp this past week who is doing similar work to get a hyper-v lab stood up 19:35:19 so maybe by end of cycle we'll have a couple of contrib testers checkout out different hypervisors! 19:36:25 notmyname: ping 19:36:29 yo 19:36:56 notmyname: so what are your thoughts on adding swift to the devstack gate? 19:38:01 jeblair: I'd need to talk to the other core devs first. when could it keep us from merging a change? 19:40:10 when a change breaks interoperability with the other prjects. or in the case of transient failures (like the test node can't download a package). or when a non-deterministic bug has crept into any included project. 19:41:54 and what problem is it solving? 19:42:27 preventing changes from being merged that break interoperability with the other projects. 19:44:36 The alternative is that a breaking change in Swift will block everyone else? 19:44:53 Right? 19:45:18 well, swift isn't tested at all in the devstack-gate right now, so breaking changes don't get noticed by the testing infrastructure. 19:45:48 jeblair: ok, I'll take it up with the rest of the core devs. can we discuss it again at next week's CI meeting? 19:46:00 sure thing. 19:46:15 jeblair: or, we can talk about it later this week after I've had a chance to talk to everyone else 19:46:24 jeblair: Ok. Can we agree that these things need to happen at around the same time? 19:46:28 okay, i'll be around 19:46:47 soren: yes, inclusion in the tests implies gating on that project, in my mind. 19:46:48 jeblair: I.e. using swift in the devstack gate and applying the same gaate to swift. 19:46:57 Good. 19:47:25 mtaylor: apache in front of git-http-backend is now live? 19:47:48 oh! yeah 19:47:51 I totally forgot 19:48:17 we're serving out git anonymous http from gerrit using straight apache and not gerrit/jgit 19:48:40 so we should never see a java thread pool limit issue preventing us from being able to clone a repo 19:48:58 also, clarkb should probably talk about the gerritbot changes 19:49:00 and similarly, those threads and stuff in the java can be spent doing helpful things 19:49:39 gerritbot has a new channel config yaml file that tells it which channels to join and what projects + events each channel cares about 19:49:53 ttx: as a result of that, we changed a replication setting- so we should no longer be replicating draft changes to github 19:50:05 ttx: so they may be more secure now - you may want to re-test their suitability 19:50:22 mtaylor: isn't gitweb still an issue? 19:50:32 is it? 19:50:49 was that where the issue was? 19:50:56 hmm, I don't think I touhced github i nmy hack :) 19:51:06 * ttx searches for bug 19:51:10 it was one place with an issue 19:51:32 we can turn it off if the tradeoff is acceptable 19:51:39 mtaylor: https://bugs.launchpad.net/openstack-ci/+bug/902052/comments/2 19:51:41 Launchpad bug 902052 in openstack-ci "Gerrit should support private reviews for security bugs" [Wishlist,Triaged] 19:52:27 gotit. well - alternate idea - use github links instead of gitweb, and we just won't have github preview links for draft changes 19:52:51 we could also have gitweb serve out the local replicas that apache is serving out, since those also will not have draft changes 19:53:19 * mtaylor may be drifting off topic 19:53:24 mtaylor: wouldn't "git https://review.openstack.org/openstack/$PROJECT" still expose the chnage somehow ? 19:53:31 ttx: nope 19:53:44 ttx: we're replicating to a set of local repo copies... 19:54:06 ttx: but we're only replicating refs that are visible to users in the authenticated users group 19:54:18 mtaylor: do it and I'll do my best breaking it :) 19:54:37 ttx: please do! check out the github replicas and the anon-http urls 19:55:27 so as for gitweb, i guess we should see if we can have the gerrit-managed gitweb use the 'public' local repos... 19:55:27 ttx: if those two are solid enough for you, we'd just have to decide whether we wanted to give up having revision preview links for draft changes 19:55:36 mtaylor: so gitweb is off-limit because it would be turned off if we were to go that way, right 19:55:37 or otherwise, shut it off. 19:55:40 jeblair: ++ 19:56:04 I need to access them *without* ging through gitweb now 19:56:05 well, it would either be shut off if we went the github route, or it would serve the local replica repos 19:56:07 going* 19:56:14 gitweb has a minor secondary use of making the other branches like meta/config easily viewable. :( 19:56:37 but people can always pull those i reckon. 19:56:45 hrm. yeah 19:57:18 time to start winding up the meeting I think 19:57:35 or down, depending on how you look at it 19:58:19 ok. anybody got anything else? 19:59:23 ... 20:00:54 #endmeeting