Infrastructure/Meetings/2007-01-04

= Meeting of 2007-01-04 =


 * Time shown in EST

15:04 <@mmcgrath> sweet, well. Lets get started. Role call 15:04 * dgilmore is here 15:04 * abadger1999 is here 15:05 * mdomsch is here 15:05 * iWolf is here 15:06 * c4chris|w is around (for once) 15:06 * skvidal is here, actually - b/c I'm at home sick 15:06 :-/ 15:06 <@mmcgrath> ick 15:06 yah, luckily I can't make you sick from here 15:06 <@mmcgrath> Thats good, - http://fedoraproject.org/wiki/Infrastructure/Schedule 15:07 <@mmcgrath> abadger1999: had any responses about the package database? 15:07 No responses. 15:07 I've got something up now. 15:07 <@mmcgrath> Are you worried about what impact brew might have on what you're doing? 15:07 https://admin.fedoraproject.org/pkgdb/ 15:07 mmcgrath: Yes. 15:08 Unfortunately, I don't know what the impact will be until I see what all's included. 15:08 * poelcat here 15:08 <@mmcgrath> f13, warren: is there anything we can do in the meantime to make sure brew won't completely change what Toshio is doing? 15:08 <@mmcgrath> poelcat: yo 15:08 i tried the web interface a bit last night and I got a 503 error 15:08 jcollie: Yeah. try it now. 15:09 mmcgrath: howdy 15:09 There's something funky in TG that I'm trying to track down. 15:09 yeah, that's better :) 15:09 -!- kschreyack [n=kschreya@ip-64-7-28-184.lax.megapath.net] has joined #fedora-admin 15:09 But for now, I just kill the old TG process if I notice it's not responding. 15:09 <@mmcgrath> abadger1999: we may just have to deal with that when the time comes 15:09 (Scripted now so that it does so automatically.) 15:10 mmcgrath: brew?  Yes. 15:10 heh heh "Fedora Extras devel: Status: EOL" :) 15:10 <@mmcgrath> we'll go on to VCS then 15:10 jcollie: :-) Yep.  It's a straight import from owners.list.  We will need to alter status and owner information and such like before going live. 15:11 <@mmcgrath> At this point the SIG is 'formed' but hasn't done anything. 15:11 <@mmcgrath> The VCS choice has been moved AFAIK to FC8 15:11 i started a wiki page with a list of operations to support 15:11 We need to get Chris Blizzard and some others involved. 15:11 but not much feedback from the sig 15:11 mmcgrath, f13: I indicated that we really need to release the brew schema sooner, jesse is working on that. 15:11 currently blocking on legal 15:11 <@mmcgrath> warren: k, thanks. 15:12 <@mmcgrath> jcollie: wiki link? 15:12 jcollie: I've been meaning to reply to your message for a week but have had other things to work on :-( 15:12 <@mmcgrath> jcollie: I might have missed the email, did it go to a list? 15:12 Basically, I think we need to be looking at an even higher level than that. 15:13 Chris Blizzard and a few others in the fedora summit proposed that the dist-cvs workflow isn't the best for developing packages. 15:13 He proposed using exploded source trees instead. 15:13 <@mmcgrath> Should we discuss the VCS at Fudcon? 15:14 mmcgrath: Yes. 15:14 mmcgrath, http://fedoraproject.org/wiki/Infrastructure/VersionControl/Operations 15:14 that would be a great thing to do. 15:14 * mmcgrath adds it to the wiki 15:14 mmcgrath, i sent it as a reply to your scm sig message 15:14 So things like lookaside cache would go away in that scenario. 15:15 <@mmcgrath> I have a love-hate with look-aside-cache. 15:15 abadger1999, no i think the lookaside would remain 15:16 <@mmcgrath> I personally do think, though, that we should version control stuff we do not 'create' if that makes sense. 15:16 <@mmcgrath> At least with lookaside cache we can remove source that is only in FC1 for example if we need to though I don't think thats optimum. 15:17 mmcgrath: one thing we are going to need to do is get alot more storage space 15:17 <@mmcgrath> dgilmore: thats a definate. *ESPECIALLY* if we're going to give hosting a shot at actually working :-) 15:17 jcollie: If the source is in the VCS, then there's no need for lookaside cache. 15:17 problem with putting big binaries into VC is that (at least with some of the VC) is that we have a collection of repos, not one large one so there's no opportinity to share 15:18 <@mmcgrath> one worrie I have about source in VCS is bloat, one issue with SVN at least is that once its there it CANNOT be removed. 15:18 <@mmcgrath> which is good and bad. 15:18 mmcgrath: well not just hosted. but i personanly like lookaside cache from an extras user point of view 15:18 They wouldn't be binaries. 15:18 does dell make a fibre channel storage system? 15:18 Their untarred so they're source trees. 15:19 abadger1999, but if you untar them it's much harder to verify that you have the same file as upstream 15:19 <@mmcgrath> Actually we should discuss this with the sig. Someone (jcollie? ;-) should setup a sig meeting for us to meet and discuss such things. 15:19 As for collection of repos, using distributed VCS's like bazaar makes sharing (as in storage space) posible and sharing (as in with upstream/other projects) also possible. 15:19 abadger1999: i still dont quite uderstand how that will help me 15:20 dgilmore: It makes managing large patchsets easier. 15:20 jcollie, we partner with EMC for FC storage 15:21 mmcgrath: yeah. and we should move the discussion onto fedora-devel too. 15:21 mdomsch, you have enough pull to get a few terabytes of storage donated :) 15:22 if we can define "a few" and in how many locations 15:22 <@mmcgrath> agreed, I think that from now on as far as VCS goes the FI team should stick to hosting and actual implementation issues. 15:22 we can try to get it out of EMC directly 15:22 -!- smooge [n=smooge@pdpc/supporter/bronze/smooge] has joined #fedora-admin 15:22 no promises here 15:22 We need to get Chris Blizzard involved in the discussion at least so he can present why he thinks exploded trees are great. 15:22 mdomsch: probably 5 to start all in pheonix 15:22 mmcgrath: +1 15:23 <@mmcgrath> even though most of the FI team is in the Sig ;-) 15:23 * dgilmore is probably the only one not in it 15:23 mmcgrath, +1 yeah we could spend all day discussing VCS here 15:23 <@mmcgrath> k, we'll move on 15:23 where is this Sig? 15:24 <@mmcgrath> iWolf: db1 upgrade. I can never remember where thats going or if you're waiting o nme. 15:24 I've completely missed it 15:24 <@mmcgrath> http://fedoraproject.org/wiki/Infrastructure/SCMSig 15:24 < iWolf> mmcgrath: the holidays were much busier than I thought. 15:24 < iWolf> jas 15:25 <@mmcgrath> no worries. 15:25 <@mmcgrath> they usually are :-) 15:26 mmcgrath: we were waiting on getting the old cvs server hardware back and in shape 15:26 <@mmcgrath> Thats right, the hard drive upgrade. 15:26 <@mmcgrath> firmware upgrade 15:26 yep 15:26 < iWolf> back 15:26 < iWolf> sorry. 15:27 <@mmcgrath> K, I've just sent a message to Stacy to find out what the status is / was for that. 15:27 < iWolf> The holidays were busy, I just need to confirm my access to teh old cvs box and set it up. 15:27 mmcgrath: was stacy going to update the firmware or a dell tech? 15:27 < iWolf> I can test the DBs before the HD firmware is udpated. 15:27 <@mmcgrath> Thats true. 15:27 <@mmcgrath> dgilmore: no idea. 15:27 < iWolf> It was going to be Stacy or mgaloci (sp?) 15:27 < iWolf> They just hadn't gotten to it yet. 15:27 <@mmcgrath> Not sure. 15:28 < iWolf> I'm thte slow one, as I can get stuff ready to go even before the firmware is updated. 15:28 < iWolf> :) 15:28 <@mmcgrath> We kind of operate out of their normal operating procedures, they actually have an internal ticketing system that they normally use and we email them directly so sometimes stuff gets forgotten. 15:28 <@mmcgrath> that will probably change soon. 15:29 <@mmcgrath> lmacken: whats up with the firewall stuff? 15:29 <@mmcgrath> Surely thats done now :-D ? 15:29 haha 15:29 nothing new with the firewall stuff.. i haven't had any spare cycles to give to it 15:29 <@mmcgrath> Yeah 15:29 it's just a matter of deployment (typing 'pyroman'), and seeing what breaks 15:30 <@mmcgrath> k 15:30 and then tweaking the configs 15:30 <@mmcgrath> warren: should we move Xen to the 'done' category? 15:30 mmcgrath: have you read davej's comments on the subject? :) 15:30 of xen, I mean 15:31 <@mmcgrath> No? 15:31 <@mmcgrath> Where were they posted? 15:31 skvidal: yeah i did 15:31 skvidal: you do mean fab list? 15:31 mmcgrath: f-a-b list a couple of weeks ago 15:31 dgilmore: yah 15:31 mmcgrath: I believe he said 'bullet in the brainpan' 15:31 he hates xen with a passion 15:31 < iWolf> yeah, he seems to be pretty against xen! 15:31 alot of our boxes should support kvm 15:32 <@mmcgrath> What thread? 15:32 umm 15:32 one sec 15:32 dgilmore, what does kvm actually gain us? 15:32 being in the kernel 15:32 warren: its upstream 15:32 mmcgrath, sure 15:33 its full virt 15:33 mmcgrath: 15:33 https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00072.html and https://www.redhat.com/archives/fedora-advisory-board/2006-December/msg00079.html 15:33 dgilmore, you're assuming that full virt is a good thing. It isn't, for our purposes. 15:33 dgilmore, paravirt is way faster and more flexilb.e 15:33 * mmcgrath reading 15:33 That won't affect us until we're ready to upgrade past RHEL5, thoug,h, unles I'm missing something? 15:33 abadger1999: you're correct - it's just something to keep in mind 15:34 b/c we're putting a bunch of eggs in a basket that a number of folks hate 15:34 warren: im not dismissing that  just that kvm will make davej happier 15:34 Xen while not upstream is at least well supported by a large company and in the product that we're using. 15:34 warren: im quite happy with xen 15:34 Nothing stops us from migrating to a different virtualization solution in the future. 15:34 skvidal: Yeah -- I've been thinking about it too but figured that we had some time to let kvm/lhype/etc stabilize to see where we want to jump. 15:34 im not saying we should. 15:34 <@mmcgrath> Does KVM use normal partitions? 15:35 Xen is in RHEL5 so we have it available for 7 years  at least 15:35 Keep in mind that full virt is NOT VERY USEFUL for our purposes. 15:35 <@mmcgrath> I mean, can we easily switch from using KVM or Xen? 15:35 mmcgrath: not sure 15:35 if we run rhel5 for 7 years then we suck :) 15:35 mmcgrath, it isn't a trivial shift, but it is possible 15:35 skvidal: yep we would if we did 15:36 but if we want to stick with xen and its dropped from RHEL6 we can stick with it 15:36 there is a good reason why management has been abstracted with libvirt 15:36 <@mmcgrath> I say for now, we stick with Xen.  If it falls through and Xensource doesn't shape up we should be able to easily migrate. 15:36 <@mmcgrath> I would think anyway. 15:36 < iWolf> isn't full virt more useful for us? 15:36 mmcgrath: +1 15:36 iWolf, no 15:36 < iWolf> No guest OS modification? 15:36 full virt is less useful 15:36 there are shaping up ways to be able to run xen guests with other virt tools 15:36 like lhype or even KVM stuff 15:37 Red Hat will need to have a migration path, so going forward with Xen isn't going to be a big deal IMHO, so long as any tools we create are built on top of libvirt 15:37 < iWolf> full virt uses the VT and AMD extensions, right? 15:37 yes 15:37 < iWolf> So what's wrong with that? 15:37 and no full virt is NOT more useful. 15:37 f13: +1 15:37 fullvirt is much slower 15:37 <@mmcgrath> yeah djones is unhappy with xen for reasons that make a lot of sense. 15:37 paravirt is faster and more flxible 15:37 so lets move on 15:38 all our guests should/will have paravirt kernels for them, so we don't need fullvirt 15:38 <@mmcgrath> he would know and " 15:38 <@mmcgrath> Upstream kernel.org seems to be heading on a different path to virtualisation^Pr^Pnanyway (KVM for full-virt and lhype for paravirt)" is very telling 15:38 <@mmcgrath> so lets keep an eye on it. 15:38 <@mmcgrath> a close eye. 15:38 mmcgrath: well, lhype isn't upstream yet, probably not for a while, but OT by now 9: 15:38 (: 15:39 <@mmcgrath> We'll move on for now, dgilmore: legacy? 15:39 RHEL5 has to be supported for 7 years, I feel pretty confident using it (or CentOS5) on any part of the Fedora infrastructure 15:39 don't worry about Xen for now, just use it, it works for us. Migration path will be provided in the future. 15:39 Legacy is a dead issue, there is no legacy. 15:39 bah 15:39 mmcgrath: i switched legacy support on the buildsys  off  when i switched off FC-3 and FC-4 15:39 I've never heard of legacy 15:40 <@mmcgrath> skvidal: some called it 'heritage' :-P 15:40 s/Legacy/Old Farts Release/ 15:40 <@mmcgrath> lmacken: updates system 15:40 <@mmcgrath> whats the word? 15:40 thunderbird 15:40 word 15:40 Update system is still coming along nicely.  I'm hoping to have basic functionality done this week, I'm just polishing up the push/metadata generation code at the moment. 15:40 I started setting up the production environment for it, created tables in postgres (although, I can move it over to mysql if people want; i don't care either way). 15:40 i hope to have something we can play with shortly 15:41 lmacken: i want to use it for EPEL 15:41 yep 15:41 that's the plan 15:41 <@mmcgrath> Fun 15:41 it could be used for anything really 15:41 i need to get stuck into my TurboGears book and jump in 15:41 skvidal: yes, I"d be drinking thunderbird if I had to keep doing legacy 15:41 lmacken: We should talk about how to do common templates for all Fedora TG sites. 15:41 even OLPC 15:41 abadger1999: yeah 15:41 <@mmcgrath> Sweet. 15:41 i hacked mine together (from a mockup dfong gave me a couple of summers ago) 15:42 I want to get nman64 and the website people involved. 15:42 lmacken: you owe us an internal version of it too (: 15:42 <@mmcgrath> Ok, I'll skip through the priority two stuff kind of quick. 15:42 it can be ass ugly, it just has to work 15:42 <@mmcgrath> Anyone else feel like we've gotten NOWHERE with the config management decisions? 15:42 f13: yup yup. the current code works (meaning sends emails around, and can push updates) 15:42 k 15:42 mmcgrath: we've generated lots of not-terribly-useful email 15:42 mmcgrath: there has been a lot of noise... 15:42 mmcgrath: here's my take 15:42 <@mmcgrath> Wasn't someone supposed to create a 'what we need' wiki page? 15:43 mmcgrath: Sorta. I think we've got three choices so far: glump, puppet, bcfg2 15:43 so the real question is this. A) who is going to be using it and B) what does that person really want to use. 15:43 mmcgrath: you're johnny in charge around here for this sort of stuff. choose one,go with it 15:43 mmcgrath: everyone in here, will jump on board 15:43 the rest of us will deal. 15:43 skvidal: :-) 15:43 seriously. I'm fine with whatever 15:43 I'm sure I'll figure it out if need be :) 15:43 * f13 too 15:43 I'm sure I'll bug skvidal to do whatever if need be. 15:44 well, except for the cvsdist/rdist thing 15:44 :) 15:44 glump will need us to do hacking -- but it's shell and python so it's possible. 15:44 <@mmcgrath> I'm not the type to say how it is, I'll write up a proposal/reason and see how it goes from there. 15:45 puppet is attractive if we don't have to hack it much 15:45 mmcgrath: grow some balls (: 15:45 abadger1999: not much hacking - I've already given all the scripts we use here at duke 15:45 bcfg2 -- no one here's used so it's an unknown. 15:45 <@mmcgrath> I haven't even looked at bcfg2 15:45 <@mmcgrath> Alrighty, moving on... 15:45 <@mmcgrath> Metrics 15:46 <@mmcgrath> The hardware profiler is coming along 15:46 <@mmcgrath> http://publictest4.fedora.redhat.com/stats 15:46 <@mmcgrath> and 15:46 <@mmcgrath> http://publictest4.fedora.redhat.com/raw 15:46 <@mmcgrath> There's some bugs in the rhn client tools but I'll be looking into that. 15:46 wait, bugs in RHN code? shocking 15:46 <@mmcgrath> The question is if we want to tie this into a reporting system for first release or just keep it a hardware / metrics mechanism. 15:46 <@mmcgrath> f13: OMG I know!1!!one! 15:47 mmcgrath: looking good thus far 15:47 'reporting system for first release' ? 15:47 <@mmcgrath> I see dgilmore has been helping me test - Aurora SPARC Linux release 2.90 (Aurora Corona) :-D 15:47 <@mmcgrath> You know how when something crashes in MS a box comes up and does a 'send error report' 15:48 <@mmcgrath> Blizzard suggested we do something similar, we could add a flag with it that says "this profile was sent with an error, here's the users description of the error" 15:48 mmcgrath, do we want UUID to be displayed in public? 15:48 <@mmcgrath> but that would have to tie into bz somehow. 15:48 mmcgrath, isn't UUID an unique identifier that could be a privacy problem? 15:48 <@mmcgrath> warren: I've gone back and forth about that, I don't think it matters since there's on way to tie it back to anyone. 15:48 <@mmcgrath> unless someone already has access to the UUID file on that persons machine. 15:49 ah 15:49 <@mmcgrath> in which case they'd have access to all the hardware info inyway. 15:49 <@mmcgrath> I'm grabbing it from /proc/sys/kernel/random/uuid 15:49 hmm 15:49 I guess 15:50 <@mmcgrath> Plus I'm hoping people will be submitting (at first at least) and saying "hey my sound won't work, my UUID is 123-123-1231231231231U 15:50 <@mmcgrath> Thats the only way for us to tie a machine to a person is if they gave it to us. 15:51 <@mmcgrath> ok, its getting later than I though. any word on SMTP? 15:51 dgilmore succeeded where I sucked. 15:51 Any decision to try sqlite to simplify it? 15:52 <@mmcgrath> dgilmore: any word on it? 15:52 im going to change it to sqllite 15:52 thats tonights job 15:53 <@mmcgrath> Awesome. 15:54 <@mmcgrath> kimo paulobanon aren't here but they've done a lot of work on proxy servers + moin and unfortunately we won't benefit from it until the next release 15:54 mmcgrath: i plan to have the metrics db full of sparc before the week is out :D 15:54 <@mmcgrath> :-D 15:55 <@mmcgrath> f13: project hosting. 15:55 <@mmcgrath> how's it going, what do you need, where do we go from here? 15:56 I still need a way to dole out raw webspace 15:56 secondly, I want to revamp how our hosted SCMs are done, move them to their own xen instance so that each can live happily alone 15:56 * mdomsch wants to get gitweb running 15:56 (different ips so that we don't have to do silly games with http/ssh) 15:57 f13, putting each hosted proj in its own xen instance will be lots and lots of xen instances over time 15:57 <@mmcgrath> f13: will the SCM we chose be related to this in any way in your mind? 15:57 f13: How many hosted projects are we planning on having? Will giving each one their own xen instanc e begin to wiegh things down? 15:58 each to manage, and each taking memory 15:58 <@mmcgrath> I mean, right now we have cvs, git and hg already. Should we let projects pick their own SCM? 15:58 mmcgrath, I'd say yes 15:58 i say let them use any scm that trac supports 15:58 f13: ibillio does it by haveing a box you ssh into with http space and web space nfs mounted 15:58 Right now it seems constrained by trac... svn, git, hg, darcs, and bzr all have trac plugins I think 15:59 s/http/ftp/ 15:59 <@mmcgrath> If we go the multiple route thing we'll need to make sure that we have the expertise on hand to handle all that. 15:59 mdomsch: no no. 16:00 mdomsch: each SCM would get its own xen, not each project. 16:00 ahh 16:00 mmcgrath: the package SCM, no, these would just be the hosted SCMs, git, hg, svn 16:00 Ah. Much better :-) 16:00 hehe 16:01 I"m not that batshit insane. 16:01 <@mmcgrath> K. 16:01 dgilmore: so long as A) one user can't put stuff in another user's webdir, and B) there is very little risk of the login box being exploited leading to further exploitation. 16:01 <@mmcgrath> How much response have you gotten from people on it internally and externally? Can we assume this will be pretty popular the day it goes live? 16:01 a config management system (like puppet :)) would help a lot in managing the hosted stuff 16:02 mmcgrath: I've gotten an OK amount of inquiries, which is neat as I"ve done 0 advertisement. 16:02 <@mmcgrath> Yeah, its basically been all word of mouth at this point. 16:02 f13: sure we would probably need to use linux acls so we can grant apache right and deny others access 16:02 mmcgrath: it'll be interesting, I imagine I'll get a lot of crap requests, somebody wanting to start a project, vaporware. 16:02 dgilmore: I'm more thinking that the box people log into to put content up is _NOT_ the box that apache runs from 16:02 f13: i want some space to start a project about projects :D 16:03 f13: sure 16:03 I don't necessarily know how to handle "is this a worthy project of us hosting" though 16:03 thats how ibilio has it setup ftp is one box http is another box you log into a thired box 16:03 and any sort of project cleanup, getting rid of vaporware. 16:03 dgilmore: makes sense, although I refuse to support ftp 16:04 I think skvidal is with me on that one. 16:04 yes, I am 16:04 <@mmcgrath> Which reminds me I've been meaning to put a "request for resources" form on the wiki. 16:04 I refuse to support f13 supporting ftp 16:04 f13: i dont want to support ftp either 16:04 yeah, down with ftp 16:04 <@mmcgrath> So that people have to actually come to us with a proposal. 16:04 but you can s/ftp/scm/ 16:05 dgilmore: you don't want to support scm? 16:06 -!- lyz [n=lyz@dsl081-149-006.chi1.dsl.speakeasy.net] has quit ["Leaving"] 16:06 f13: no scm can be used instead of f 16:06 tp 16:06 <@mmcgrath> ahh 16:06 have nfs mounts for things that might be needed from the login box 16:06 login.fedoraproject.org :D 16:07 reminds me how do i change dns? 16:07 i want to add smtp.fedoraproject.org 16:07 <@mmcgrath> its on lockbox 16:07 <@mmcgrath> in the cvs, the 'ns-master' host IIRC, we run DNS in a chroot 16:08 <@mmcgrath> mdomsch: anything to add on mirror management? 16:08 I need to work on the schema a lot 16:08 <@mmcgrath> how bad was it? 16:08 not horrible, but definitely needs work 16:08 dgilmore: well, hopefully one would have the ability to do say 'createrepo mydir/' for an upstream repo and not have to try and commit that through an SCM 16:09 jcollie noted it would be useful to have a tool to automatically populate the db 16:09 which really makes sense considering data we can't see externally pre-bitflip 16:09 dgilmore: 'login.hosted.fedoraproject.org' seperate it out even more. 16:09 f13: no they should be able to do that from login box in their http space 16:09 right 16:09 <@mmcgrath> auto populate from what data? 16:09 so there'll be a web UI, and a tool to run after rsync on the mirror servers 16:10 that client-side tool can walk the directory structure, see what's mirrored, and update the db 16:10 f13: login.hosted.fedoraproject.org is good 16:10 <@mmcgrath> Ahh, so someone logs in and says "I have a mirror" and our side says "here's what you're mirroring" ? 16:11 yeah 16:11 or more likely 16:11 <@mmcgrath> will they have the ability to override what we specify? 16:11 "I have a mirror, here's aht it is" 16:11 <@mmcgrath> s/specify/find/ 16:11 pre-bitflip 16:12 there's also a concept I'm toying with, coherent vs mirrored 16:12 coherent is yesterday's data before I start mirroring today's data 16:12 incoherent is some of both yesterdays and todays data 16:12 <@mmcgrath> Cool, well keep us informed. Right now our current 'check script' won't scale well we should figure out a good, reliable way to do that. 16:12 and mirrored is we all agree 16:14 <@mmcgrath> Alrighty, open floor. Does anyone have anything to add before we go? 16:14 I haven't kept up to date on this, but has anything come of the "New bugzilla instance" discussion after the Fedora Summit? 16:14 Should we try and find someone to head that up? 16:14 I don't think that may be realizable for F7 release 16:14 give everything else. 16:14 mmcgrath: I'd like to get a fairly good sized Xen Guest ready for test Wort deployments 16:15 ok.. 16:15 <@mmcgrath> f13: is someone internally driving that or should one of us drive it? 16:15 -!- snerd [n=snerdlet@ppp32-194.lns1.syd6.internode.on.net] has joined #fedora-admin 16:15 mmcgrath: define "that" 16:15 <@mmcgrath> s/that/our own bugzilla instnace/ 16:15 lmacken: AFAIK we need to have a way for bugzilla to talk to each other first 16:15 Did we decide we wanted our own bugzilla? 16:16 I can't see a lot of advantage to it unless we have someone who wants to hack on bugzilla for us. 16:16 mmcgrath: I don't know of anybody driving that, no. 16:16 abadger1999: we want a bugzilla.fedoraproject.org but need a XML-RPC type inteface to move bugs to Red Hat's bugzilla. or upstream bug tools 16:17 dgilmore, what's the driving force behind having our own bugzilla? 16:17 <@mmcgrath> the two biggest advantages are A) Single Sign On and B) being able to do something about it in the event of an outage. 16:17 <@mmcgrath> SSO for Fedora at least. 16:17 taking confusion away from users. signle sign on for all fedora infrastructre 16:17 anywho, the Br^Wort code is on its way to being released, I'd like to be able to jump on it when that happens, and that means having a xen guest ready for it (RHEL5Beta?) and some NFS mounts where we can throw builds. 16:18 * mdomsch posits that b) isn't super-critical - if RH's bugzilla is down, their I/T folks shoudl be on it like ugly on an ape 16:18 <@mmcgrath> Lets just say we and RH had OpenID installed, can bugzilla use that? 16:18 f13: can i cvs co it yet? 16:18 f13: xen2  has some space 16:19 mmcgrath: probably with work 16:19 Is there work being done somewhere to create bugzilla openid auth? 16:19 http://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin 16:19 dgilmore: no, the code hasn't gotten its legal review. 16:20 mdomsch: Looks broken. 16:20 <@mmcgrath> We're going to love OpenID when the time comes. 16:20 f13: can you let me know as soon as i can get my grubby little hands on it please 16:20 ie: bugzilla has moved on and the patch needs updating 16:21 mmcgrath: Why?  Are there openid providers that we trust enough to let them auth for us? 16:21  * f13 thought OpenID was just a layer to some other backend, and you still need to support something like ldap 16:21 openid just is a common place/layer to have the username. 16:21 <@mmcgrath> abadger1999: possibly though I think the idea was for us to become a provider. 16:21 Or are we just gatewaying from our ldap anyways... so it's just another layer? 16:22 Exactly. So what does openid give us that going straight from ldap does not? 16:23 abadger1999: others could trust our Fedora OpenID source? 16:23 <@mmcgrath> abadger1999: early adoptation of a technology that is proving very popular, it'd tie in easily with mugshot for example and other sites. 16:23 abstraction 16:23 <@mmcgrath> f13: yep 16:25 f13: That's true if everyone starts buying in. We'll have to see. 16:25 <@mmcgrath> Alrighty, this has been a long one. Should we call a meeting end? 16:25 mmcgrath: i think so 16:25 sure 16:25 -!- tibbs [n=tibbs@fedora/tibbs] has quit ["Konversation terminated!"] 16:25 <@mmcgrath> alrighty 30 16:25 No further questions, your honor :-) 16:26 <@mmcgrath> 20 16:26 <@mmcgrath> 10 16:26 <@mmcgrath> 5 16:26 <@mmcgrath> ============ Meeting End =================