19:02:00 <mtaylor> #startmeeting
19:02:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:35 <mtaylor> first order of business ... hey jaypipes, anytihng new with tempest this week?
19:03:21 <jaypipes> mtaylor: you're kiddin, right? :)
19:04:02 <jeblair> pretty sure something notable happened regarding tempest...
19:04:05 <mtaylor> jaypipes: I'm not! it was a leading question
19:04:40 <jeblair> i'm ecstatic.  it's something we've wanted to do since the essex design summit!
19:05:19 <jaypipes> mtaylor: what jeblair said :)
19:05:29 <jaypipes> mtaylor: we are now gating core projects on the tempest smoke tests.
19:05:49 <jeblair> jaypipes: so what do we need to do before we can stop running exercise.sh?
19:05:55 <jaypipes> 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 <mtaylor> jaypipes: w00t!
19:06:07 <mtaylor> jaypipes: that's super exciting!
19:06:08 <jaypipes> jeblair: I just need to do the analysis gap coverage
19:06:20 <jaypipes> jeblair: put a bug in on openstack-ci and assign to me?
19:06:27 <jeblair> jaypipes: will do!
19:07:06 <jeblair> jaypipes: just keep in mind devstack-gate isn't running all the exercise scripts, so it may not be that bad.
19:07:39 <jaypipes> jeblair: k. everything but boot from volume, right?
19:07:44 <soren> 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 <soren> So we should be able to use the same gate there.
19:08:16 <jeblair> soren: oh good, those are going to come in handy real soon i bet.  :)
19:08:31 <jaypipes> nice
19:08:44 <jeblair> 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 <soren> Dunno. I've only tested it with one configuration, so maybe.
19:09:50 * mtaylor does a little dance
19:10:04 <soren> ...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 <soren> Anyway, carry on.
19:11:13 <mtaylor> I think that's it on that one.
19:11:23 <mtaylor> jeblair: you had something to do with that one, anything else interesting from you?
19:11:23 <jeblair> on a related note...
19:11:45 <jeblair> i'm working on adding more flexibility to zuul regarding which jobs are run and how...
19:12:17 <jeblair> 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 <jeblair> (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 <mtaylor> yup
19:13:57 <mtaylor> agree
19:14:24 <mtaylor> speaking of zuul - clarkb, did you add a feature people might care about this week?
19:14:59 <clarkb> there were some minor tweaks to the status page and you can now retrigger jobs by leaving comments on changes
19:15:18 <clarkb> a comment of "recheck" retriggers check jobs and a comment of "reverify" retriggers gate jobs
19:16:06 <LinuxJedi> clarkb: if I say "reverify" 10 times straight on one review will zuul poo itself?
19:16:12 <clarkb> potentially
19:16:19 <LinuxJedi> awesome :)
19:16:42 <jeblair> yeah, adding 'skip enqueuing a second build set for the same change' is a todo.  :)
19:17:09 <mtaylor> what does zuul poo look like?
19:17:34 * LinuxJedi python exceptions I guess
19:17:50 <jeblair> a big jenkins backlog.
19:18:00 * LinuxJedi doesn't know why I did /me there
19:18:00 <mtaylor> heh. you said log
19:18:09 <mtaylor> ANYWAY
19:18:09 <LinuxJedi> better than drizzledump
19:18:26 <mtaylor> LinuxJedi: what's the status of stackforge?
19:18:27 <jeblair> hey, i'm eating here.
19:18:38 <LinuxJedi> well, we had lots of fun last week...
19:18:50 <LinuxJedi> a bug in HP Cloud completely blew away Stackforge Jenkins
19:19:09 <LinuxJedi> so we had 2 options: 1. rebuild, 2. go with the migration plan we talked about a couple of weeks ago
19:19:33 <LinuxJedi> 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 <LinuxJedi> but keep github stuff separate
19:20:09 <LinuxJedi> the US was out celebrating the fact they kicked us out
19:20:18 <jeblair> yay us!
19:20:22 <mtaylor> woohoo!
19:20:24 <LinuxJedi> so I made the decision to do option 2
19:20:27 <mtaylor> stinky british people
19:20:33 <LinuxJedi> lol :)
19:20:46 <LinuxJedi> and the migration went pretty smoothly considering
19:21:04 <LinuxJedi> so Stackforge now uses review.openstack.org and jenkins.openstack.org
19:21:20 <LinuxJedi> and that is about it
19:21:49 <LinuxJedi> 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 <soren> Where are they instaed?
19:22:29 <soren> Rackspace?
19:22:35 <soren> Just curious.
19:22:39 <mtaylor> soren: we're just using the openstack ones
19:22:43 <mtaylor> soren: which are all at rackspace
19:22:44 <LinuxJedi> soren: they are part of Openstack's gerrit and jenkins, so yes
19:22:49 <soren> Ok.
19:23:35 <LinuxJedi> on a positive note that gives us another tenant in HP Cloud to do evil things with
19:23:41 <mtaylor> 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 <clarkb> devananda's openvz devstack stuff will apparently do evil things
19:24:51 <LinuxJedi> mtaylor: that is an unlimited tenant, so knock yourself out ;)
19:24:58 <mtaylor> LinuxJedi: BALLER
19:25:12 <jeblair> oh, we should get openstackjenkins to be unlimited...
19:25:21 <mtaylor> yeah - how do we do that?
19:25:36 <LinuxJedi> jeblair: ok, I assumed they were all unlimited, because I didn't hit a limit when I did crazy stuff
19:25:41 <mtaylor> jeblair: also, I just sent you email, but we have blockstorage enabled now on that hpcloud tenant
19:26:08 <jeblair> oh, i think devstack-launch hits a quota sometimes.
19:26:23 <jeblair> mtaylor: that's great, i should be able to finish backups soon then!
19:26:26 <mtaylor> 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 <mtaylor> jeblair: w0t!
19:26:32 <LinuxJedi> damn, they aren't unlimited then, that broke my world a bit
19:28:15 <mtaylor> 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 <mtaylor> and am continuing to work on an openstack-requires repo
19:29:03 <mtaylor> 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 <clarkb> more dramatic then different versions?
19:30:30 <mtaylor> well, no - just different versions
19:30:48 <LinuxJedi> damn, I was hoping for a 'Dallas' kind of drama
19:30:49 <mtaylor> but it's interesting to see VERY specific version pins in pip-requires that are not what we install for devstack :)
19:31:50 <mtaylor> devananda: how's openvz coming along?
19:32:06 <devananda> we got the nova driver code from rackspace last week
19:32:27 <devananda> so i spent several days figuring out how to get it to work with our ubuntu kernel
19:32:28 <LinuxJedi> devananda now has square eyes reading through it all
19:32:34 <devananda> and it does :)
19:32:54 <devananda> on my bare metal box at home, i've got a working devstack with oepnvz containers and bridged networking
19:33:03 <mtaylor> yay
19:33:48 <devananda> one or two issues to work out with the networking, and i should be able to start running tests on it
19:34:26 <mtaylor> excellent. which means we can then start actually get a jenkins stood up to do that regularly
19:34:38 <devananda> indeed
19:34:56 <mtaylor> 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 <mtaylor> so maybe by end of cycle we'll have a couple of contrib testers checkout out different hypervisors!
19:36:25 <jeblair> notmyname: ping
19:36:29 <notmyname> yo
19:36:56 <jeblair> notmyname: so what are your thoughts on adding swift to the devstack gate?
19:38:01 <notmyname> jeblair: I'd need to talk to the other core devs first. when could it keep us from merging a change?
19:40:10 <jeblair> 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 <notmyname> and what problem is it solving?
19:42:27 <jeblair> preventing changes from being merged that break interoperability with the other projects.
19:44:36 <soren> The alternative is that a breaking change in Swift will block everyone else?
19:44:53 <soren> Right?
19:45:18 <jeblair> 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 <notmyname> 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 <jeblair> sure thing.
19:46:15 <notmyname> jeblair: or, we can talk about it later this week after I've had a chance to talk to everyone else
19:46:24 <soren> jeblair: Ok. Can we agree that these things need to happen at around the same time?
19:46:28 <jeblair> okay, i'll be around
19:46:47 <jeblair> soren: yes, inclusion in the tests implies gating on that project, in my mind.
19:46:48 <soren> jeblair: I.e. using swift in the devstack gate and applying the same gaate to swift.
19:46:57 <soren> Good.
19:47:25 <clarkb> mtaylor: apache in front of git-http-backend is now live?
19:47:48 <mtaylor> oh! yeah
19:47:51 <mtaylor> I totally forgot
19:48:17 <mtaylor> we're serving out git anonymous http from gerrit using straight apache and not gerrit/jgit
19:48:40 <mtaylor> so we should never see a java thread pool limit issue preventing us from being able to clone a repo
19:48:58 <LinuxJedi> also, clarkb should probably talk about the gerritbot changes
19:49:00 <mtaylor> and similarly, those threads and stuff in the java can be spent doing helpful things
19:49:39 <clarkb> 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 <mtaylor> 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 <mtaylor> ttx: so they may be more secure now - you may want to re-test their suitability
19:50:22 <jeblair> mtaylor: isn't gitweb still an issue?
19:50:32 <mtaylor> is it?
19:50:49 <mtaylor> was that where the issue was?
19:50:56 <ttx> hmm, I don't think I touhced github i nmy hack :)
19:51:06 * ttx searches for bug
19:51:10 <clarkb> it was one place with an issue
19:51:32 <clarkb> we can turn it off if the tradeoff is acceptable
19:51:39 <ttx> mtaylor: https://bugs.launchpad.net/openstack-ci/+bug/902052/comments/2
19:51:41 <uvirtbot> Launchpad bug 902052 in openstack-ci "Gerrit should support private reviews for security bugs" [Wishlist,Triaged]
19:52:27 <mtaylor> 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 <mtaylor> 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 <ttx> mtaylor: wouldn't "git https://review.openstack.org/openstack/$PROJECT" still expose the chnage somehow ?
19:53:31 <mtaylor> ttx: nope
19:53:44 <mtaylor> ttx: we're replicating to a set of local repo copies...
19:54:06 <mtaylor> ttx: but we're only replicating refs that are visible to users in the authenticated users group
19:54:18 <ttx> mtaylor: do it and I'll do my best breaking it :)
19:54:37 <mtaylor> ttx: please do! check out the github replicas and the anon-http urls
19:55:27 <jeblair> 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 <mtaylor> 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 <ttx> mtaylor: so gitweb is off-limit because it would be turned off if we were to go that way, right
19:55:37 <jeblair> or otherwise, shut it off.
19:55:40 <mtaylor> jeblair: ++
19:56:04 <ttx> I need to access them *without* ging through gitweb now
19:56:05 <mtaylor> well, it would either be shut off if we went the github route, or it would serve the local replica repos
19:56:07 <ttx> going*
19:56:14 <jeblair> gitweb has a minor secondary use of making the other branches like meta/config easily viewable.  :(
19:56:37 <jeblair> but people can always pull those i reckon.
19:56:45 <mtaylor> hrm. yeah
19:57:18 <LinuxJedi> time to start winding up the meeting I think
19:57:35 <LinuxJedi> or down, depending on how you look at it
19:58:19 <mtaylor> ok. anybody got anything else?
19:59:23 <heckj> ...
20:00:54 <mtaylor> #endmeeting