19:02:16 #startmeeting infra 19:02:17 Meeting started Tue Jun 18 19:02:16 2013 UTC. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:21 The meeting name has been set to 'infra' 19:02:37 #topic Rename of the project formerly known as mutnuaq (mordred) 19:02:46 oh wow. I'm first 19:02:53 markmcclain: around yet? 19:03:08 so - mutnuaq has gotten names back from legal 19:03:09 (the only action from last meeting has a this-meeting agenda item) 19:03:17 nice 19:03:26 and we _believe_ they've picked a name 19:03:28 yay 19:03:29 which means - 19:03:31 drumroll 19:03:34 now we actually have to rename it 19:03:39 oh man 19:03:48 which, being mutnuaq, means it's WAY more complex than any rename we've ever done 19:03:52 o/ 19:03:52 because things consume it 19:03:55 forgot to waive earlier. 19:04:01 o/ 19:04:02 * mordred waves at jlk 19:04:17 markmcclain: how solid are we on that provisional name choice? 19:04:36 98% 19:04:47 that's so much closer than we were before 19:05:11 I think the first step is to do renames in the repos with compatibility packages 19:05:17 how ingrained is the old name beyond that project/client and devstack{,-gate} and infra/config? is it deeply embedded in other projects? 19:05:30 fungi: nova consumes quantumclient at least 19:05:36 joyous 19:05:38 yeah 19:05:47 mordred: can we just depend on both? 19:05:55 well, the working idea 19:05:55 then after the switch remove the old name? 19:05:58 is in the current repos 19:06:00 nova is the big one.. I need to look over ceilometer and heat to double check 19:06:10 add do the package rename and then add a new package in the same repo 19:06:20 that does a bunch of from newname import * 19:06:24 in its __init__.py files 19:06:32 grep -r 'quantum' nova | grep '\.py:' | wc -l 19:06:32 1798 19:06:42 just to get an idea of how much that name is in nova 19:06:46 so that then the dependent projects can start working on getting their renames done 19:07:03 gah 19:07:14 that's going to be fun 19:07:17 yup 19:07:29 good opportunity for upstream commits :) 19:07:35 jlk: hehe 19:07:44 then we'll need to schedule a gerrit renaming downtime 19:07:46 please tell me it's 7 characters? 19:07:54 * markmcclain counts 19:07:55 yep 19:07:56 so we aren't in pep8 19:07:58 hell 19:08:05 well, that's something :) 19:08:08 sort order might change slightly for hacking hell 19:08:10 grep -c ^.......$ /usr/share/dict/words 19:08:27 question is - 19:08:37 yeh, the imports will be one thing, at least it won't require massive reformatting though 19:08:45 do we try to make devstack and destack-gate attempt to clone from both names? 19:08:47 oh yeah that would suck 19:08:54 or do we force-push changes to those when we do the rename? 19:09:09 mordred: i'd rather force-push those changes 19:09:13 * mordred too 19:09:32 it creates a definitive switch point which is nice 19:09:33 I think the in-python trickery with double package names is enough trickery for one rename 19:09:44 and is simpler if you can live with a potentially broken gate over the shrot term 19:09:45 i think that is the least complicated, even if it does mean possible breakage and subsequent manual patching to get going again 19:10:29 I'm assuming we shoudl schedule a non-trivial downtime - like, an assumption the gate may be down for a couple of hours while we sort it and make sure it's good to move forward 19:10:36 ++ 19:10:52 BUT - I think we want the in-code renaming to be finished first, yeah? 19:10:52 i suspect a couple hours is probably being optimistic 19:10:57 and it would be good to have markmcclain and some core devs from other projects around to help during the maint window 19:11:08 jeblair: yes 19:11:29 let me know when I'll be around 19:11:43 fungi: it's true that our test cycle is an hour, so it could take a while. 19:11:52 any project we might conceivably have to cram patches into should probably have representatives awake and responding 19:12:13 ++ 19:12:18 mordred: i think that's a sensible way to proceed (code rename first) 19:12:46 mordred: i'm not sure it's necessary from a gating standpoint, but probably makes the most sense overall. 19:12:49 cool. so, markmcclain will come back to us when the code-level rename is done and we're ready to move forward with repo+devstack+devstack-gate rename? 19:13:02 jeblair: yeah. I mean, I'ts just one less thign to do that day 19:13:14 or, yeah, no, you're right 19:13:17 it could go in either order 19:13:58 mordred: but this way we won't ever produce a newthing tarball that only contains quantum 19:14:20 mordred: we'll be making quantum tarballs that are future-compat with newthing, and newthing tarballs that are backwards compat with quantum 19:14:22 which seems nicer 19:14:38 and possibly able to accomadet problems we're not anticpating. :) 19:14:38 yeah 19:14:44 +100 19:14:48 this is going to be a fun one 19:15:23 mordred: eot? 19:15:26 I think that's all I had, yeah 19:15:32 yay a plan! 19:15:58 #action markmcclain will come back to us when the code-level rename is done and we're ready to move forward with repo+devstack+devstack-gate rename 19:16:08 #topic Asterisk (jeblair, reed) 19:16:17 i don't think reed can make the meeting 19:16:34 but i think he's becomming more keen on having an asterisk server 19:16:51 he did seen rather cool with the idea 19:16:55 er, seem 19:16:58 for: (a) user-group remote participation 19:17:03 (b) summit remote participation 19:17:13 (c) foundationy things 19:17:44 (the usual conf call sorts of things -- a conference call resource like the eclipse foundation has) 19:17:45 so... what was the scale of conference call you were on with eclipse foundation folks? tens? hundreds? 19:17:53 fungi: tens 19:17:54 tens 19:17:58 oh we've done that before in Fedora infrastructure 19:17:58 (ran an Asterisk server) 19:17:58 it had very low participation 19:17:58 but it was SO CLEAR 19:18:08 jeblair: I could even see it being useful when freenode is having a hard time :) 19:18:20 clarkb: that's what oftc is for ;) 19:18:29 jlk: did you have regular conference calls and people chose to use something else? 19:18:36 jlk: or just people didn't care to make voice calls? 19:19:52 mordred: people didn't care to make voice calls 19:19:53 and there were a lot of codec and mute and echo problems 19:20:50 so maybe we should send an email to the infra list and see if folks want to chime in on setting one up? 19:21:00 While not OSS, at work we use Team Speak. Seems to be much better voice quality, and push to talk was pretty important 19:21:10 jeblair: ++ I have a feeling that folks like pabelanger would be interested 19:21:21 and I think there are many of us that don't have the bandwidth for that right now 19:21:29 jlk: jeblair and I were on a call with eclpse foundation the other day 19:21:39 jlk: and it was literally the clearest conference call I've ever been on 19:21:43 heh 19:21:44 for use cases a and b this is basically conference/speaker phone allowing remote participation with the in-room conversations, and in a way that is less bandwidth-intensive and nonfree/proprietary than g* hangouts 19:21:45 yeah it can be awesome 19:21:47 it was beatiful 19:21:54 SO much better than HP's conference call system 19:21:55 this was a few years ago though, so some of these problems may be better 19:22:46 Also, the VOIP client set may be better these days. Back then on Linux it wasn't a great set of choices 19:23:14 and communicating the settings for those clients was … fun. That all said, all this could be better, I'm not going to be a Debbie Downer ;) 19:23:20 my voice client of choice is a telephone anyway 19:23:51 yeah. I was dialed in to the asterisk server with my cell phone 19:23:56 but understood that voip software is a nice addition 19:24:12 jlk: yeah, and i think with webrtc, we can have an in-browser client 19:24:45 jlk: which i think will be especially good for the remote-listening case. 19:25:32 mordred: i was dialed in on a SIP phone through my asterisk server over POTS :) 19:25:41 nice 19:26:00 mordred: but that's just because i didn't notice their SIP url until right before the call. 19:26:10 * mordred imagines opening iax ports for jeblair's asterisk server so we can all get to him by dialing a special extension on the foundation server 19:26:35 okay, so basically we bug pabelanger and... who else? was Ryan_Lane the other person expressing interest in helping with it? 19:26:45 fungi: russellb was 19:26:49 right! 19:27:07 * fungi recalibrates his branes 19:27:18 i asked the eclipse folks about their voip provider, so i have their recommendations there 19:27:30 awesome 19:27:36 because their provider was great 19:28:04 yeah, there are a lot of bad ones out there, so having a good one to start with should be a huge benefit 19:28:16 yep, happy to help with some asterisk config 19:28:26 at least manual config ... i would be a n00b at puppetizing it 19:28:33 woo! 19:28:43 perhaps pabelanger has some puppet laying around 19:28:46 he does 19:28:47 russellb: i think pabelanger said he already had soe 19:28:49 some 19:28:58 Fedora project probably still has some puppet laying around in a git repo somewhere too 19:28:58 #action jeblair start a ml thread about asterisk 19:29:00 ages old 19:29:13 jlk: if you can find that, i'd love to see it 19:29:19 jlk: awesome! we use ages old puppet ;) 19:29:31 and if there's anyone really keen on learning asterisk, i can hook you up with a PDF of the book 19:29:41 just msg me 19:30:35 russellb: thanks! 19:30:45 #topic Progress on reviewing git web interfaces (pleia2) 19:30:52 #link https://bugs.launchpad.net/openstack-ci/+bug/1182179 19:30:53 Launchpad bug 1182179 in openstack-ci "Create a git.openstack.org mirror system" [Low,Triaged] 19:31:00 right, so last week we talked about evaluating some git web things 19:31:06 I took some notes here: 19:31:08 #link https://etherpad.openstack.org/git-1182179 19:31:43 I think we don't want gitlab, it has all kinds of stuff we really don't need, pretty much tries to be an open source github 19:32:10 which leaves us with cgit, gitblit or just same old gitweb 19:32:16 not gitweb 19:32:20 so my question is - what is it we want exactly that gitweb is failing us with? 19:32:25 cgit has been the better performing tool 19:32:41 with Fedora repos, gitweb would just stall out and crash servers 19:32:45 ouch 19:33:03 cgit is very compelling, but I don't know if it lacks features people want 19:33:16 does cgit work now without libgit? 19:33:35 like, wasn't there a time where it was impossible to package because it used non-supported git internal apis? 19:33:36 good question 19:33:42 i added https://git.kernel.org/cgit/ to the etherpad as a demo for cgit 19:33:56 jeblair: thanks 19:34:02 * mordred believes that's the reason we did not switch to cgit when the guy from libreoffice suggested it a while back 19:34:04 mordred: I don't know 19:34:14 I like the cgit index page, btw 19:34:22 http://pkgs.fedoraproject.org/cgit/ 19:34:24 that's Fedora's 19:34:36 it's not in ubuntu 19:34:46 ooh it's prettier 19:34:49 Fedora switched it it in…. 2011 or so 19:34:51 (fedora's cgit) 19:35:05 though i don't know why there are a bunch of numbers at the bottom 19:35:14 gitblit isn't packaged either, so I think either one will have challenges (though we do have WMF folks to poke about gitblit, since they use it) 19:35:20 oh those are pages. 19:35:23 Fedora has it in Fedora releases and CentOS 19:35:26 er 19:35:28 EPEL 19:35:34 we could potentially use centos + epel then 19:35:49 we almost have Fedora slaves *in the mix*. 19:35:58 good point 19:36:02 Just one postgres module issue that I know off but that wouldn't effect this... 19:36:05 I don't see any libgit deps here http://koji.fedoraproject.org/koji/rpminfo?rpmID=4034369 19:36:14 I'm ok with using it if there are packages from someone 19:36:27 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515793 19:36:28 Debian bug 515793 in wnpp "RFP: cgit -- C-code Web Front-end to GIT" [Wishlist,Open] 19:36:31 then again, I don't see any requirements on git itself either. wat 19:36:35 I do like the org groupings in the kernel.org index page 19:37:56 yeah. looks like the outstanding issue is the "this requires git internals to work" one 19:38:38 mordred: reading down to the end, i think they're okay with creating a cgit package from the git source, but there's no volunteer to mantain it. :( 19:38:50 yah 19:38:59 I seem to remember this is where we stalled last time 19:39:21 I would just suggest using the EPEL packages 19:39:29 since that's what Fedora is doing, shared interest in keeping them working. 19:39:37 also likely what kernel.org is doing 19:40:13 yeah. I mean, we at least know there are other folks looking at it 19:40:30 https://git.wikimedia.org/activity/ 19:40:30 * fungi wonders if red hat are bundling a private copy of libgit in the package 19:40:47 ooh 19:40:57 fungi: I doubt it 19:41:06 we're pretty uptight about that kind of thing 19:41:12 but you can easily clone and find out! 19:41:17 I mean, gitblit does have going for it that wikimedia run it too, and all the rest of our stuff is identical 19:41:23 mordred: yeah 19:41:38 gitblit does have a lot of sparkle, for sure 19:41:39 mordred: also lucene but that may not be useable without a lot fo work 19:41:46 rss feeds 19:41:48 or rather browse http://pkgs.fedoraproject.org/cgit/cgit.git/ 19:42:00 heh 19:42:17 oh geez 19:42:25 my inclination is to use cgit unless we feel we really need something gitblit provides 19:42:29 welp, I'm wrong 19:42:37 that spec has both the git source and the cgit source 19:42:44 and it uses both to build the package. 19:42:55 looks like... yeah 19:42:57 we spoke with Ryan_Lane and ^demon about some of their gitblit problems and it didn't sound very pleasant 19:43:15 re: searching, lucene 19:43:15 i doubt the activity stats will be compelling for us since we have at least 3 entire programs around trying to get meaningful stats 19:43:39 and we have an rss feed thing too. 19:44:01 jeblair: I thnk we're up to 4 stats programs now 19:44:06 i think the most likely thing from gitblit we'd be interested in using is the searching. 19:44:07 heh 19:44:10 5. I count five 19:44:22 and it doesn't sound like we're actually interested in dealing with those problems right now. :) 19:44:22 always room for a sixth! (seventh? eighth?!?) 19:44:26 jeblair: ++ 19:44:43 so maybe lets focus on cgit then? 19:44:45 fixing search is something ^demon at WMF is looking at, but it's low on his priority list 19:44:46 yeah i'm leaning toward cgit as well, based on the options 19:44:47 fungi: don't make too many jokes, I know of an unannounced sixth 19:44:55 fungi, jeblair: ++ 19:45:05 cgit on centos/fedora then? 19:45:18 I can spin up cgit on a centos hpcloud instance to test how it goes 19:45:22 cgit on centos/fedora sounds fine to me (with a preference for centos) 19:45:31 that sounds reasonable. we can already use the launch script to do centos with no further tweaking 19:46:00 since we build centos unit test slaves with it now 19:46:05 fungi: ah, coolo 19:46:06 -o 19:46:40 I've already stated my opinion, but I'll state it again, cgit on centos is where I'd go. 19:46:47 thanks jlk 19:47:05 jlk: looks like you won this time 19:47:10 sounds good to me 19:47:27 crap, now you're going to make me do it aren't you? 19:47:34 curses. and gitweb would have gotten away with it too if it weren't from you meddling kids 19:47:35 haha ++ 19:47:52 ok, how do we want to action this forward? 19:47:53 * fungi can't type. sigh 19:48:20 pleia2: do you want to continue working on it? work with jlk? give the whole project to jlk? :) 19:48:36 pleia2: i would suggest getting a skeleton for the server in puppet and i'll be happy to spin up a vm for that 19:48:45 i think the next step is to merge a change that defines the host, then we spin it up, then we reconfig gerrit to replicate there 19:48:57 as fungi said. :) 19:49:36 ok, I'll get it rolling and ask jlk for help :) 19:49:46 awesome 19:50:02 yup, I'll lend whatever hand I can 19:50:07 the gerrit replication part is fairly trivial. we'll also want some fancy rewrites on review.o.o to punch its gitweb links that direction 19:50:19 which may mostly be asking my Fedora contacts how they did whatever. 19:50:23 #action pleia2, jlk make git.openstack.org exist 19:50:26 fungi: I think you can do that in the gerrit config too 19:50:32 jlk: great, thank you 19:50:35 oh, even better 19:50:43 clarkb, fungi: yeah, we'll have gerrit just link there directly 19:50:47 yup 19:51:11 as long as it's flexible enough to be able to build the urls cgit expects, sounds ideal 19:51:29 or other way around (cgit smart enough to handle gitweb queries) 19:51:43 jeblair: do you know if it's possible to make gerrit's fetch links redirect there too? 19:52:00 jeblair: would be neat if the fetch/pull/cherry-pick stuff gave people git.o.o links 19:52:05 https://review.openstack.org/Documentation/config-gitweb.html 19:52:46 mordred: i don't know, but that may be overkill 19:53:23 mordred: i doubt they get used all that often 19:53:59 #topic open discussion 19:54:03 i know i only use them when i want to check out a change on a machine where i don't have git-review 19:54:43 but maybe there are lots of people who don't use git-review or don't know about its -d option 19:54:43 logstash.opensatck.org is now reverse proxying a subset of the elasticsearch API so that sdague (and hopefully others) can do programmatic search queries 19:54:53 cool 19:54:57 hey, so zuul is using gearman to send jobs to jenkins now 19:54:57 you can hit that with a base url of http://logstash.openstack.org/elasticsearch/ 19:55:16 jeblair: \o/ 19:55:18 jeblair: woot! 19:55:34 clarkb: we can use that to write something that searches logstash for queries embedded in launchpad bugs 19:55:38 davidlenwell is working on an owncloud server 19:55:42 jeblair: yup 19:55:43 oh, some progress on the py3k testing. dprince made an awesome pip3 puppet package provider which i was able to get working on precise with the help of zul's ppa 19:55:49 clarkb: to auto-identify new instances of bugs we know about. that'll be neat. 19:56:10 so,this NY bootstrap thing 19:56:13 as I told the triplo folks yesterday, lxc-based testing is going well, hopefully just hunting down the final gremlins 19:56:13 mordred: is there anything we need to do to prepare for training next week? 19:56:17 jlk: yup? 19:56:20 mordred: can you tell us more, and what will happen on each day? 19:56:39 I don't know that jeblair and I have gotten that far in the planning yet 19:56:40 I could probably get funding to go for one day, but it'd be a tough sell, and I"d have to fly home that night on a red eye or something 19:57:11 mordred, jeblair - let me know if you need help with anything 19:57:46 jeblair: we shoudl probably brainstorm what we think the general structure is going to be at least 19:57:53 jlk: where are coming from? 19:58:07 mordred: yes, i think we can do that 19:58:15 fungi: Seattle 19:58:24 long ass flight, I'm --- not likely going to come 19:58:27 zaro: and I don't know that we've identified any homework needed - I think I'm assuming there will be at least one person there who has never heard of anything we do 19:58:34 mordred: i can work with you on that today or thursday. 19:58:34 jlk: oof, yeah that's a rough day trip 19:58:40 jeblair: let's say thursday 19:58:50 I can help thursday too if you need more brains/eyes 19:58:53 I've done the boot strap thing with clarkb a couple months ago, that's probably sufficient 19:59:09 jlk: since you're in seattle you can likely convince the locals there to rehash for you after 19:59:09 jlk: indeed. it'll probably be largely like that except with more people 19:59:11 yeah we had a good short brain dump thing at linuxfest NW 19:59:35 ok, I feel better about missing it. 19:59:43 I've been wanting an excuse to get to NY, but not for just one day 19:59:47 greets 19:59:54 jlk: yeah, i think it might be redundant, so don't worry about it. 19:59:56 o hai CaptTofu 20:00:03 and that's time ;) 20:00:10 heya mr. mordred 20:00:10 jlk: come to convention center if you want more. but definately more fun in NY. 20:00:16 jeblair: time to close :) 20:00:21 thanks everyone! 20:00:23 #endmeeting