Meeting of 2006-11-02
*** Time shown in EST
16:00 < jwatson> Current UTC: Thursday, November 2, 2006 at 21:00:57
16:01 < jwatson> we having a meeting today?
16:03 < warren> yes
16:03 < warren> anyone else here?
16:03 -!- c4chris [firstname.lastname@example.org] has joined #fedora-admin
16:04 < warren> http://fedoraproject.org/wiki/Infrastructure/Schedule Meeting Agenda is here.
16:04 < f13> I'm here.
16:04 < warren> iWolf mentioned that he has a conflicting meeting.
16:04 < warren> mmcgrath, dgilmore?
16:04 < warren> lmacken had school things to attend to.
16:04 < c4chris> I'm here (provided my ADSL modem behaves...)
16:04 < abadger1999> I'm here
16:04 < mmcgrath> yo
16:04 < mmcgrath> I think we're an hour late :D
16:05 < dgilmore> warren: im here
16:05 < warren> Are we?
16:05 < warren> oh
16:05 * mmcgrath makes mental note
16:05 < mmcgrath> day light savings.
16:05 < warren> I'm a little busy doing several things now, so I'd like to state a status update of Core + Extras merge first.
16:06 < mmcgrath> warren: have at it.
16:06 < warren> Red Hat has some political blockers to deal with to make it a reality. And we have a major meeting to figure out the Red Hat s
ide of this story November 12th-15th with a few people flying in for this purpose.
16:06 < etc_> re
16:06 < warren> Meanwhile testing and improving f13's model mercurial based package VCS would be very helpful.
16:07 < warren> If we can prove that it is a great and working alternative that satisfies all needs before November 12th, then it would make it more likely that we can use it for Core + Extras merge.
16:07 < warren> Getting the packages merged into a single repository is the first step. We can integrate Package Database and other parts later.
16:07 < warren> f13, where is the plague instance running?
16:07 < c4chris> warren, how do we test it? Is there a howto somewhere ?
16:08 -!- etcwrk [email@example.com] has quit [Read error: 110 (Connection timed out)]
16:08 < f13> warren: publictest1.fedora.redhat.com
16:08 < warren> f13, could you post about your mercurial + plague instance on fedora-infrastructure-list?
16:08 -!- etc_ is now known as etcwrk
16:08 < f13> I've got a generic user 'firstname.lastname@example.org' added in and certs ready for anybody who wants them.
16:08 < f13> warren: sure.
16:08 < warren> thanks.
16:08 < f13> I'd really like to take a breather day, and then start in on dist-git
16:08 < warren> Oh, you suspect it is worth comparing mercurial to git?
16:09 < f13> there are some very strong urges inside Red Hat to use git instead of HG, so I want to give it a try.
16:09 < f13> yes.
16:09 < warren> I was under the impression that mercurial had benefits in ACL control over git.
16:09 < warren> Worth comparing yes.
16:09 < f13> depends, I have to investigate.
16:09 < f13> I haven't setup the ACLs for mercurial either yet.
16:09 -!- mrclos [email@example.com] has joined #fedora-admin
16:09 < warren> ACL's in mercurial would require a custom plugin.
16:09 < warren> but it is fairly straightforward and upstream mercurial is excited to help us.
16:09 < f13> warren: hrm, not from what I've seen.
16:09 < abadger1999> f13: Can you move your hg page under infrastructure?
16:10 < f13> I thought they had ACLs at a repo level
16:10 < f13> abadger1999: sure.
16:10 < abadger1999> (I'm watching for changes to Infrastructure/*)
16:10 < mmcgrath> hmm
16:10 < warren> f13, oh I see. With one repo per package/branch, we can use upstream's existing ACL support no problem.
16:10 < f13> yep.
16:10 < f13> warren: thats one of the advantages of my layout
16:10 < warren> f13, my earlier investigation was into having a repository with package/branch dirs, and that required custom ACL
16:10 < f13> that and isolated changesets.
16:10 < warren> Yeah
16:10 < warren> I like tihs.
16:10 < warren> this.
16:11 < f13> it wasn't too difficult to edit up Makefile.common or plague, only 4 files in plague I think (plus config file)
16:11 < warren> Any other questions or concerns regarding VCS? Otherwise we move on.
16:11 < mmcgrath> none here.
16:12 < warren> f13, we could improve both the Makefile and plague systems to more easily handle different VCS systems.
16:12 < warren> Livna's svn hacks could be abstracted in a similar way too.
16:12 < f13> warren: plague system yes, Makefile, I'm not so sure there is value in supporting multiple VCS systems.
16:12 < dgilmore> warren: thats one of the things i have been planing on adding to plague
16:12 < dgilmore> along with a few different things
16:12 < warren> f13, alrighty.
16:13 < f13> warren: I've talked to dcbw about making VCS something pluggable in plague, but its a bit more of a larger project.
16:13 < dgilmore> bbl
16:14 < mmcgrath> warren: you still MCing?
16:14 < warren> I could.
16:15 < mmcgrath> have at it ;-)
16:15 < warren> OK, next topic.
16:15 < warren> Package Database
16:15 < warren> hm... ok... next
16:15 < warren> Hm..
16:15 < warren> mmcgrath, my heart isn't in this. I'm distracted by two other things.
16:16 < mmcgrath> hehe no problem.
16:16 < warren> mmcgrath, and it seems we don't have many people here.
16:16 < mmcgrath> Not too many, thats just a good excuse to go quick.
16:16 < mmcgrath> Ok, dglmore's gone for the package database.
16:16 < mmcgrath> iWolf: everything still on hold till we get the dell's back?
16:16 * mmcgrath remembers iWolf might be a bit late.
16:16 < mmcgrath> we'll assume on hold.
16:16 < mmcgrath> lmacken: ping?
16:17 < warren> mmcgrath, he said he's busy with school
16:17 < warren> I think
16:18 < f13> yeah, he's doing a school thing.
16:18 < f13> <lmacken> hey guys, I won't be able to make the meeting today. I have to meet with a lab group from 4-6.
16:18 < mmcgrath> ahh, got'cha.
16:19 < mmcgrath> ok, Xen's been going great.
16:19 < mmcgrath> (next item xen)
16:19 < mmcgrath> We haven't really talked about this but does anyone think we shouldn't go the Xen route?
16:19 < abadger1999> What if a xen server goes down? Are too many eggs in one basket?
16:20 < abadger1999> Or will we have the capacity to host those xen instances on our other xen servers?
16:20 < mmcgrath> its possible. but I think the alternative is not providing a service at all :D
16:20 < mmcgrath> we'll try to spread it out as best we can, especially with the app/proxy servers.
16:20 < mmcgrath> but, for example, CVS. I'm a fan of taking a xen box with only one xen guest on it.
16:21 < mmcgrath> that way we could move that Xen guest if need be.
16:21 < etcwrk> if xen can handle a shared FS you might be able to fail them over, I have no idea if it's that advanced yet though
16:21 < etcwrk> though of course you'd need something to host a shared FS for you too
16:21 < warren> If we show the success of Xen to provide services for Fedora, we could more easily make a case to buy a shared storage solution.
16:22 < warren> We currently however *SHOULD* be making backups, enabling us to recover from a xen host failure very rapidly.
16:22 < warren> Just create the guest elsewhere, restore from backups and proceed.
16:22 < etcwrk> also, what is there going to be for backup on those boxes?
16:22 < warren> In the past without Xen, we couldn't bring services back online rapidly in this manner.
16:22 < warren> Sadly, I'm not familiar with our backup mechanisms. How well are they documented?
16:22 < mmcgrath> https://admin.fedoraproject.org/BackupPC/
16:23 < mmcgrath> it'll change as soon as we get that dell back. Change as in become more robust.
16:23 < warren> Anyhow, shared storage would be nice to have, but we can already bring services back online fairly quickly with Xen + backups.
16:23 < warren> Shared storage would enable us to bring guests back within SECONDS instead of an hour.
16:23 < mmcgrath> actually xen now supports live switchover :D provided a box doesn't completely die on its own.
16:24 * mmcgrath has never actaully done that though.
16:24 < warren> Shared storage would allow live switch-over, or bringing up that guest elsewhere rapidly after a complete host failure.
16:24 < mmcgrath> both actually :D
16:24 < warren> Pre-Xen: Days or weeks to get a service back.
16:24 < warren> Xen: hours to get a service back
16:24 < warren> Xen + Shared Storage: minutes or seconds
16:25 < mmcgrath> yeah. here's to keeping our fingers crossed.
16:25 < mmcgrath> dgilmore: back yet to talk about the legacy builders?
16:25 < mmcgrath> f13: how's that going?
16:27 < f13> meh
16:27 < f13> I haven't really put much effort into it yet
16:27 * f13 looks at lmacken for an update tool
16:27 < mmcgrath> yeah, you've been busy
16:27 < mmcgrath> So thats all the priority one stuff.
16:27 < mmcgrath> Just a heads up Kimo and paulobanon are looking into putting the wiki behind our proxies.
16:28 -!- etc_ [firstname.lastname@example.org] has joined #fedora-admin
16:28 < mmcgrath> They're also going to look into how much mod_cache vs squid cache would help performance.
16:28 < f13> awesome
16:28 < mmcgrath> That should be coming down the pipe fairly soon.
16:28 * etc_ catches up
16:29 < mmcgrath> I've been looking at skvidal's config management system.
16:29 < mmcgrath> I'm hoping to be able to get at least some of our configs in there to proof of concept it to everyone else.
16:29 < mmcgrath> I'll keep everyone informed on that.
16:30 < mmcgrath> I've given lyz a dump of our database minus the passwords for the new LDAP database. i think thats going well.
16:30 < mmcgrath> Thats really all I've got (based off of who is here)
16:30 < mmcgrath> anyone have anything else to say?
16:30 < abadger1999> Oh -- VCS question: Is there any reason we'd need symlinks or empty directories within the repository?
16:30 < lyz> mmcgrath, thanks for the dump
16:30 < mmcgrath> lyz: hey!
16:31 < mmcgrath> is that what you needed?
16:31 < abadger1999> I noticed mercurial doesn't do either of those but I can't think of any reason we'd need them.
16:31 < lyz> mmcgrath, haven't checked yet. I will check it tonight
16:31 < mmcgrath> abadger1999: hmm.
16:31 < mmcgrath> lyz: cool.
16:31 < warren> our Makefile system doesn't need symlinks
16:31 < warren> and if a directory contains at least a makefile, no problem =)
16:31 < mmcgrath> abadger1999: I can think of needs for that in the fedora infrastruture but not for general development.
16:31 < f13> abadger1999: the only thing I can think of for symlinks is the common repo
16:32 < warren> f13, for what?
16:32 < abadger1999> f13: As in symlinking to files in the common repo instead of including it in each package repo?
16:32 < f13> something sortof like that
16:32 < f13> with CVS common is a symlink I do believe to a top level common
16:33 < f13> with dist-hg, I just manually checkout the top level common and put it in package/
16:33 < f13> so I don't think we need symlinks or emptydirs
16:33 < abadger1999> At the repo level or the working directory level?
16:33 < f13> at either level
16:33 -!- abompard [email@example.com] has joined #fedora-admin
16:34 < abadger1999> Err -- in reference to "with CVS common is a symlink I do believe to a top level common"
16:34 < abadger1999> It seems you've solved it for dist-hg.
16:35 < f13> I solved it yea
16:35 < abadger1999> How do you update common if the files change?
16:36 < f13> part of the make command is cd ../common; hg pull -u
16:36 -!- dbewley [firstname.lastname@example.org] has quit ["Leaving"]
16:36 < f13> (I think I remember doing that)
16:36 < abadger1999> k.
16:36 * iWolf back from work meeting
16:36 -!- p3n [email@example.com] has quit [Read error: 104 (Connection reset by peer)]
16:36 < f13> I think the cvs version did the same thing, cd ../common; cvs up
16:37 -!- p3n [firstname.lastname@example.org] has joined #fedora-admin
16:38 -!- farshad_ [email@example.com] has joined #fedora-admin
16:38 -!- farshad_ [firstname.lastname@example.org] has quit [Client Quit]
16:38 -!- tibbs [n=tibbs@fedora/tibbs] has quit ["Konversation terminated!"]
16:38 -!- farshad_ [email@example.com] has joined #fedora-admin
16:38 < mmcgrath> Ok, does anyone have anything else? If not I'll close the meeting and we can continue discussing CVS?
16:40 -!- etcwrk [firstname.lastname@example.org] has quit [Read error: 110 (Connection timed out)]
16:40 -!- etc_ is now known as etcwrk
16:40 < mmcgrath> ---- CLOSED --- :D