Infrastructure/Meetings/2007-01-04

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 < skvidal> :-/
15:06 <@mmcgrath> ick
15:06 < skvidal> 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 < abadger1999> No responses.
15:07 < abadger1999> 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 < abadger1999> https://admin.fedoraproject.org/pkgdb/
15:07 < abadger1999> mmcgrath: Yes.
15:08 < abadger1999> 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 < jcollie> i tried the web interface a bit last night and I got a 503 error
15:08 < abadger1999> jcollie: Yeah.  try it now.
15:09 < poelcat> mmcgrath: howdy
15:09 < abadger1999> There's something funky in TG that I'm trying to track down.
15:09 < jcollie> yeah, that's better :)
15:09 -!- kschreyack [n=kschreya@ip-64-7-28-184.lax.megapath.net]  has joined #fedora-admin
15:09 < abadger1999> 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 < abadger1999> (Scripted now so that it does so automatically.)
15:10 < abadger1999> mmcgrath: brew?  Yes.
15:10 < jcollie> heh heh "Fedora Extras devel: Status: EOL" :)
15:10 <@mmcgrath> we'll go on to VCS then
15:10 < abadger1999> 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 < jcollie> i started a wiki page with a list of operations to support
15:11 < abadger1999> We need to get Chris Blizzard and some others involved.
15:11 < jcollie> but not much feedback from the sig
15:11 < warren> mmcgrath, f13: I indicated that we really need to release the brew schema sooner, jesse is working on that.
15:11 < warren> currently blocking on legal
15:11 <@mmcgrath> warren: k, thanks.
15:12 <@mmcgrath> jcollie: wiki link?
15:12 < abadger1999> 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 < abadger1999> Basically, I think we need to be looking at an even higher level than that.
15:13 < abadger1999> 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 < abadger1999> He proposed using exploded source trees instead.
15:13 <@mmcgrath> Should we discuss the VCS at Fudcon?
15:14 < abadger1999> mmcgrath: Yes.
15:14 < jcollie> mmcgrath, http://fedoraproject.org/wiki/Infrastructure/VersionControl/Operations
15:14 < abadger1999> that would be a great thing to do.
15:14  * mmcgrath adds it to the wiki
15:14 < jcollie> mmcgrath, i sent it as a reply to your scm sig message
15:14 < abadger1999> 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 < jcollie> 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 < dgilmore> 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 < abadger1999> jcollie: If the source is in the VCS, then there's no need for lookaside cache.
15:17 < jcollie> 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 < dgilmore> mmcgrath: well not just hosted.  but i personanly like lookaside cache from an extras user point of view
15:18 < abadger1999> They wouldn't be binaries.
15:18 < jcollie> does dell make a fibre channel storage system?
15:18 < abadger1999> Their untarred so they're source trees.
15:19 < jcollie> 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 < abadger1999> 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 < dgilmore> abadger1999: i still dont quite uderstand how that will help me
15:20 < abadger1999> dgilmore: It makes managing large patchsets easier.
15:20 < mdomsch> jcollie, we partner with EMC for FC storage
15:21 < abadger1999> mmcgrath: yeah.  and we should move the discussion onto fedora-devel too.
15:21 < jcollie> mdomsch, you have enough pull to get a few terabytes of storage donated :)
15:22 < mdomsch> 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 < mdomsch> 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 < mdomsch> no promises here
15:22 < abadger1999> 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 < dgilmore> mdomsch: probably 5 to start all in pheonix
15:22 < dgilmore> 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 < jcollie> mmcgrath, +1 yeah we could spend all day discussing VCS here
15:23 <@mmcgrath> k, we'll move on
15:23 < warren> 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 < warren> 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 < dgilmore> 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 < dgilmore> 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 < dgilmore> 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 < lmacken> haha
15:29 < lmacken> nothing new with the firewall stuff.. i haven't had any spare cycles to give to it
15:29 <@mmcgrath> Yeah
15:29 < lmacken> it's just a matter of deployment (typing 'pyroman'), and seeing what breaks
15:30 <@mmcgrath> k
15:30 < lmacken> and then tweaking the configs
15:30 <@mmcgrath> warren: should we move Xen to the 'done' category?
15:30 < skvidal> mmcgrath: have you read davej's comments on the subject? :)
15:30 < skvidal> of xen, I mean
15:31 <@mmcgrath> No?
15:31 <@mmcgrath> Where were they posted?
15:31 < dgilmore> skvidal: yeah i did
15:31 < dgilmore> skvidal: you do mean fab list?
15:31 < skvidal> mmcgrath: f-a-b list a couple of weeks ago
15:31 < skvidal> dgilmore: yah
15:31 < skvidal> mmcgrath: I believe he said 'bullet in the brainpan'
15:31 < dgilmore> he hates xen with a passion
15:31 < iWolf> yeah, he seems to be pretty against xen!
15:31 < dgilmore> alot of our boxes should support kvm
15:32 <@mmcgrath> What thread?
15:32 < skvidal> umm
15:32 < skvidal> one sec
15:32 < warren> dgilmore, what does kvm actually gain us?
15:32 < skvidal> being in the kernel
15:32 < dgilmore> warren: its upstream
15:32 < warren> mmcgrath, sure
15:33 < dgilmore> its full virt
15:33 < skvidal> mmcgrath:
15:33 < skvidal>  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 < warren> dgilmore, you're assuming that full virt is a good thing.  It isn't, for our purposes.
15:33 < warren> dgilmore, paravirt is way faster and more flexilb.e
15:33  * mmcgrath reading
15:33 < abadger1999> That won't affect us until we're ready to upgrade past RHEL5, thoug,h, unles I'm missing something?
15:33 < skvidal> abadger1999: you're correct - it's just something to keep in mind
15:34 < skvidal> b/c we're putting a bunch of eggs in a basket that a number of folks hate
15:34 < dgilmore> warren: im not dismissing that   just that kvm will make davej happier
15:34 < warren> Xen while not upstream is at least well supported by a large company and in the product that we're using.
15:34 < dgilmore> warren: im quite happy with xen
15:34 < warren> Nothing stops us from migrating to a different virtualization solution in the future.
15:34 < abadger1999> 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 < dgilmore> im not saying we should.
15:34 <@mmcgrath> Does KVM use normal partitions?
15:35 < dgilmore> Xen is in RHEL5  so we have it available for 7 years  at least
15:35 < warren> 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 < dgilmore> mmcgrath: not sure
15:35 < skvidal> if we run rhel5 for 7 years then we suck :)
15:35 < warren> mmcgrath, it isn't a trivial shift, but it is possible
15:35 < dgilmore> skvidal: yep we would if we did
15:36 < dgilmore> but if we want to stick with xen and its dropped from RHEL6  we can stick with it
15:36 < warren> 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 < dgilmore> mmcgrath: +1
15:36 < warren> iWolf, no
15:36 < iWolf> No guest OS modification?
15:36 < warren> full virt is less useful
15:36 < f13> there are shaping up ways to be able to run xen guests with other virt tools
15:36 < f13> like lhype or even KVM stuff
15:37 < f13> 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 < f13> yes
15:37 < iWolf> So what's wrong with that?
15:37 < f13> and no full virt is NOT more useful.
15:37 < abadger1999> f13: +1
15:37 < f13> fullvirt is much slower
15:37 <@mmcgrath> yeah djones is unhappy with xen for reasons that make a lot of sense.
15:37 < warren> paravirt is faster and more flxible
15:37 < dgilmore> so lets move on
15:38 < f13> 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 < f13> mmcgrath: well, lhype isn't upstream yet, probably not for a while, but OT by now 9:
15:38 < f13> (:
15:39 <@mmcgrath> We'll move on for now, dgilmore: legacy?
15:39 < f13> 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 < warren> don't worry about Xen for now, just use it, it works for us.  Migration path will be provided in the future.
15:39 < f13> Legacy is a dead issue, there is no legacy.
15:39 < smooge> bah
15:39 < dgilmore> mmcgrath: i switched legacy support on the buildsys  off  when i switched off FC-3 and FC-4
15:39 < skvidal> I've never heard of legacy
15:40 <@mmcgrath> skvidal: some called it 'heritage' :-P
15:40 < smooge> s/Legacy/Old Farts Release/
15:40 <@mmcgrath> lmacken: updates system
15:40 <@mmcgrath> whats the word?
15:40 < skvidal> thunderbird
15:40 < lmacken> word
15:40 < lmacken> 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 < lmacken> 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 < lmacken> i hope to have something we can play with shortly
15:41 < dgilmore> lmacken: i want to use it for EPEL
15:41 < lmacken> yep
15:41 < lmacken> that's the plan
15:41 <@mmcgrath> Fun
15:41 < lmacken> it could be used for anything really
15:41 < dgilmore> i need to get stuck into my TurboGears book and jump in
15:41 < f13> skvidal: yes, I"d be drinking thunderbird if I had to keep doing legacy
15:41 < abadger1999> lmacken: We should talk about how to do common templates for all Fedora TG sites.
15:41 < lmacken> even OLPC
15:41 < lmacken> abadger1999: yeah
15:41 <@mmcgrath> Sweet.
15:41 < lmacken> i hacked mine together (from a mockup dfong gave me a couple of summers ago)
15:42 < abadger1999> I want to get nman64 and the website people involved.
15:42 < f13> 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 < f13> 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 < lmacken> f13: yup yup.  the current code works (meaning sends emails around, and can push updates)
15:42 < f13> k
15:42 < skvidal> mmcgrath: we've generated lots of not-terribly-useful email
15:42 < f13> mmcgrath: there has been a lot of noise...
15:42 < skvidal> mmcgrath: here's my take
15:42 <@mmcgrath> Wasn't someone supposed to create a 'what we need' wiki page?
15:43 < abadger1999> mmcgrath: Sorta.  I think we've got three choices so far: glump, puppet, bcfg2
15:43 < f13> 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 < skvidal> mmcgrath: you're johnny in charge around here for this sort of stuff. choose one,go with it
15:43 < skvidal> mmcgrath: everyone in here, will jump on board
15:43 < f13> the rest of us will deal.
15:43 < abadger1999> skvidal: :-)
15:43 < skvidal> seriously. I'm fine with whatever
15:43 < skvidal> I'm sure I'll figure it out if need be :)
15:43  * f13 too
15:43 < f13> I'm sure I'll bug skvidal to do whatever if need be.
15:44 < skvidal> well, except for the cvsdist/rdist thing
15:44 < skvidal> :)
15:44 < abadger1999> 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 < abadger1999> puppet is attractive if we don't have to hack it much
15:45 < f13> mmcgrath: grow some balls (:
15:45 < skvidal> abadger1999: not much hacking - I've already given all the scripts we use here at duke
15:45 < abadger1999> 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 < f13> 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 < f13> mmcgrath: looking good thus far
15:47 < f13> '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 < warren> mmcgrath, do we want UUID to be displayed in public?
15:48 <@mmcgrath> but that would have to tie into bz somehow.
15:48 < warren> 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 < f13> 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 < warren> hmm
15:49 < warren> 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 < warren> dgilmore succeeded where I sucked.
15:51 < warren> Any decision to try sqlite to simplify it?
15:52 <@mmcgrath> dgilmore: any word on it?
15:52 < dgilmore> im going to change it to sqllite
15:52 < dgilmore> 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 < dgilmore> 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 < f13> I still need a way to dole out raw webspace
15:56 < f13> 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 < f13> (different ips so that we don't have to do silly games with http/ssh)
15:57 < mdomsch> 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 < abadger1999> 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 < mdomsch> 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 < mdomsch> mmcgrath, I'd say yes
15:58 < jcollie> i say let them use any scm that trac supports
15:58 < dgilmore> f13: ibillio does it by haveing a box you ssh into with http space and web space nfs mounted
15:58 < abadger1999> Right now it seems constrained by trac... svn, git, hg, darcs, and bzr all have trac plugins I think
15:59 < dgilmore> 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 < f13> mdomsch: no no.
16:00 < f13> mdomsch: each SCM would get its own xen, not each project.
16:00 < mdomsch> ahh
16:00 < f13> mmcgrath: the package SCM, no, these would just be the hosted SCMs, git, hg, svn
16:00 < abadger1999> Ah. Much better :-)
16:00 < f13> hehe
16:01 < f13> I"m not that batshit insane.
16:01 <@mmcgrath> K.
16:01 < f13> 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 < jcollie> a config management system (like puppet :)) would help a lot in managing the hosted stuff
16:02 < f13> 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 < dgilmore> f13: sure we would probably need to use linux acls  so we can grant apache right and deny others access
16:02 < f13> mmcgrath: it'll be interesting, I imagine I'll get a lot of crap requests, somebody wanting to start a project, vaporware.
16:02 < f13> 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 < dgilmore> f13: i want some space to start a project about projects :D
16:03 < dgilmore> f13: sure
16:03 < f13> I don't necessarily know how to handle "is this a worthy project of us hosting" though
16:03 < dgilmore> thats how ibilio has it setup ftp is one box http is another box  you log into a thired box
16:03 < f13> and any sort of project cleanup, getting rid of vaporware.
16:03 < f13> dgilmore: makes sense, although I refuse to support ftp
16:04 < f13> I think skvidal is with me on that one.
16:04 < skvidal> 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 < skvidal> I refuse to support f13 supporting ftp
16:04 < dgilmore> f13: i dont want to support ftp either
16:04 < jcollie> yeah, down with ftp
16:04 <@mmcgrath> So that people have to actually come to us with a proposal.
16:04 < dgilmore>  but you can s/ftp/scm/
16:05 < f13> 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 < dgilmore> f13: no scm can be used instead of f
16:06 < dgilmore> tp
16:06 <@mmcgrath> ahh
16:06 < dgilmore> have nfs mounts  for things that might be needed from the login box
16:06 < dgilmore> login.fedoraproject.org :D
16:07 < dgilmore> reminds me how do i change dns?
16:07 < dgilmore> 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 < mdomsch> I need to work on the schema a lot
16:08 <@mmcgrath> how bad was it?
16:08 < mdomsch> not horrible, but definitely needs work
16:08 < f13> 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 < mdomsch> jcollie noted it would be useful to have a tool to automatically populate the db
16:09 < mdomsch> which really makes sense considering data we can't see externally pre-bitflip
16:09 < f13> dgilmore: 'login.hosted.fedoraproject.org' seperate it out even more.
16:09 < dgilmore> f13: no they should be able to do that from login box  in their http space
16:09 < f13> right
16:09 <@mmcgrath> auto populate from what data?
16:09 < mdomsch> so there'll be a web UI, and a tool to run after rsync on the mirror servers
16:10 < mdomsch> that client-side tool can walk the directory structure, see what's mirrored, and update the db
16:10 < dgilmore> 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 < mdomsch> yeah
16:11 < mdomsch> or more likely
16:11 <@mmcgrath> will they have the ability to override what we specify?
16:11 < mdomsch> "I have a mirror, here's aht it is"
16:11 <@mmcgrath> s/specify/find/
16:11 < mdomsch> pre-bitflip
16:12 < mdomsch> there's also a concept I'm toying with, coherent vs mirrored
16:12 < mdomsch> coherent is yesterday's data before I start mirroring today's data
16:12 < mdomsch> 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 < mdomsch> and mirrored is we all agree
16:14 <@mmcgrath> Alrighty, open floor.  Does anyone have anything to add before we go?
16:14 < lmacken> 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 < lmacken> Should we try and find someone to head that up?
16:14 < f13> I don't think that may be realizable for F7 release
16:14 < f13> give everything else.
16:14 < f13> mmcgrath: I'd like to get a fairly good sized Xen Guest ready for test Wort deployments
16:15 < lmacken> 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 < f13> mmcgrath: define "that"
16:15 <@mmcgrath> s/that/our own bugzilla instnace/
16:15 < dgilmore> lmacken: AFAIK we need to have a way for bugzilla to talk to each other first
16:15 < abadger1999> Did we decide we wanted our own bugzilla?
16:16 < abadger1999> I can't see a lot of advantage to it unless we have someone who wants to hack on bugzilla for us.
16:16 < f13> mmcgrath: I don't know of anybody driving that, no.
16:16 < dgilmore> 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 < mdomsch> 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 < dgilmore> taking confusion away  from users.  signle sign on for all fedora infrastructre
16:17 < f13> 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 < dgilmore> f13: can i cvs co it yet?
16:18 < dgilmore> f13: xen2  has some space
16:19 < dgilmore> mmcgrath: probably with work
16:19 < abadger1999> Is there work being done somewhere to create bugzilla openid auth?
16:19 < mdomsch> http://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin
16:19 < f13> dgilmore: no, the code hasn't gotten its legal review.
16:20 < abadger1999> mdomsch: Looks broken.
16:20 <@mmcgrath> We're going to love OpenID when the time comes.
16:20 < dgilmore> f13: can you let me know as soon as i can get my grubby little hands on it please
16:20 < abadger1999> ie: bugzilla has moved on and the patch needs updating
16:21 < abadger1999> 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 < f13> 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 < abadger1999> Or are we just gatewaying from our ldap anyways... so it's just another layer?
16:22 < abadger1999> Exactly.  So what does openid give us that going straight from ldap does not?
16:23 < f13> 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 < dgilmore> abstraction
16:23 <@mmcgrath> f13: yep
16:25 < abadger1999> 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 < dgilmore> mmcgrath: i think so
16:25 < f13> sure
16:25 -!- tibbs [n=tibbs@fedora/tibbs]  has quit ["Konversation terminated!"] 
16:25 <@mmcgrath> alrighty 30
16:25 < abadger1999> No further questions, your honor :-)
16:26 <@mmcgrath> 20
16:26 <@mmcgrath> 10
16:26 <@mmcgrath> 5
16:26 <@mmcgrath> ============ Meeting End =================