Infrastructure/Meetings/2007-01-18

= Meeting of 2007-01-18 =


 * Time shown in EST

14:59 <@mmcgrath> Meeting! You guys about ready? 14:59 aye aye captain!!! 15:02 <@mmcgrath> abadger1999, warren, skvidal, iWolf, dgilmore, f13, kim0: ping 15:02 pong 15:02 <@mmcgrath> role call! who's here? 15:02 here 15:02 -!- mmcgrath changed the topic of #fedora-admin to: meeting in progress 15:02 I'm in a meeting 15:02 so I'll be slow to respond 15:02 <@mmcgrath> skvidal: This meeting! 15:02 <@mmcgrath> :-) 15:02 no, another one 15:02 sorry 15:02 * dgilmore is here 15:02 :) 15:03 <@mmcgrath> Before I get to http://fedoraproject.org/wiki/Infrastructure/Schedule I wanted to ask if everyone had a chance to look at http://fedoraproject.org/wiki/Infrastructure/RFR 15:04 you know i have :) 15:04 <@mmcgrath> and the template, we can always add stuff as we go but I think this is a good start considering we didn't really have anything like it in the past. 15:04 mmcgrath: i had a quick look at it 15:04 it looks pretty good 15:04 looks good to me 15:04 -!- lyz [n=lyz@dsl081-149-006.chi1.dsl.speakeasy.net] has joined #fedora-admin 15:05 Would be good to have a list of the open RFRs 15:05 Otherwise looks good. 15:05 one thought regarding the Template 15:05 the template should have a free-form area to describe how the resource would be used 15:05 <@mmcgrath> abadger1999: I'm going to try to contact the xen owners individually. 15:05 paragraphs 15:06 <@mmcgrath> I was kind of hoping thats what project plan and goals would be.  Like here - http://fedoraproject.org/wiki/Infrastructure/RFR/DocsProjectPlone 15:07 was just thinking that there should be an "official use only" section that documents approved/denied and what resources were granted 15:07 <@mmcgrath> Also its my intention that any infrastructure officer can sponsor any outstanding project, especially when its a proof of concept. 15:07 <@mmcgrath> There's no need to get approval from others unless its going to be an abnormal burden on our resources. 15:08 <@mmcgrath> Then when the time comes to go live we can decide together the best way to proceed. 15:08 :) 15:09 abadger1999, using categories would make it easy to track RFRs 15:09 <@mmcgrath> ok, on to the schedule. 15:09 mmcgrath: we need to make sure the publictest instances are approved 15:09 the only one i know we did discuss was f13's hosted 15:09 And f13's hgtest 15:09 <@mmcgrath> dgilmore: hmmm, we can do that. 15:10 mmcgrath: thats something we agreed to do  it hasnt been followed 15:10 <@mmcgrath> Thats true, I'm guilty of that as well. 15:10 though AFAIKT  the ones that are up all look fine 15:10  * mmcgrath forgot 15:10 crap, I forgot about this meeting. 15:10 again. 15:10 I'm here. 15:11  * dgilmore slaps f13   wake up :) 15:11 -!- mmcgrath changed the topic of #fedora-admin to: Package Database 15:11 <@mmcgrath> abadger1999: whats the word? 15:11 -!- snerd [n=snerdlet@fedora/robk] has joined #fedora-admin 15:11 I've got a TG identity and visit plugin :-) 15:12 It ties into our present FAS. 15:12 <@mmcgrath> very nice 15:12 It's for sqlalchemy so I have to test it with lmacken's code as well. 15:12 (of someone else using sqlobject) 15:13 I think that the FAS should be able to use SA while the main project uses SO but I want to check. 15:13 <@mmcgrath> k. 15:13 f13, btw, is the brew schema coming sooner, or brew itself is coming soon? 15:13 Did anyone look at: http://www.fedoraproject.org/wiki/Infrastructure/AccountSystem2/API 15:14 I'm wondering if it's worthwhile to continue working on that as a general purpose API or not. 15:14 <@mmcgrath> I think it is. How hard will it be to port that to LDAP? 15:14 <@mmcgrath> err to use ldap 15:15 mmcgrath: It's a bit hard for me to say as I don't know LDAP too well :-( 15:15 I glanced at the python-ldap docs this weekend 15:15 And I think things will map okay. 15:15 abadger1999, don't let "general purpose" stand in the way of getting it done. Has it been a burden? 15:15 < daMaestro> i think having a general purpose API will help us use any backend we want 15:15 But my ignorance of LDAP shows. 15:15 <@mmcgrath> abadger1999: we can focus on that during FUDCon 15:15 warren: Not really. 15:16 This is the fourth project I've worked on that uses fas and I just got tired of using website.py 15:16 So I took all the little gripes I had accumulated from using it on the others and rolled an API I was happier with. 15:16 <@mmcgrath> heh 15:17 < daMaestro> i expect ldap should be pretty easy, i might jump in and help abadger1999 on the api 15:17 daMaestro: That would be appreciated. 15:18 Let me know how you'd like to collaborate. 15:18 < daMaestro> ok 15:18 <@mmcgrath> daMaestro: BTW, please fill one of these out for your xen instance - http://fedoraproject.org/wiki/Infrastructure/RFR 15:19 -!- mmcgrath changed the topic of #fedora-admin to: VCS choice 15:19 <@mmcgrath> So the SIG has basically sat here. 15:20 <@mmcgrath> We'll try to get together a bit during FudCON for those that are there. 15:20 speaking of ldap. FDS should be ready Very soon now for a review for Fedora 15:20 <@mmcgrath> iwolf didn't ping in so I'll assume he's gone, same with lmacken 15:20 -!- mmcgrath changed the topic of #fedora-admin to: Xen (smtp) 15:20 <@mmcgrath> warren: any news? 15:20 mmcgrath: I'll write a VCS announce for fedora-devel to kick off some pre-FudCON thinking. 15:21 <@mmcgrath> abadger1999: that would be fantastic 15:21 mmcgrath, I'm in the process of upgrading spamassassin for RHEL-4.5, right now actually 15:21 mmcgrath, that should be the last piece 15:22 mmcgrath, it seems that sqlgrey on smtp is still setup for mysql. Did we want that or sqlite? 15:22 <@mmcgrath> for now I'd say sqlite 15:22 OK, I'll reconfigure that. 15:22 warren: i didnt get a chance to change it :( 15:22 dgilmore, I'll handle it, don't worry. 15:22 <@mmcgrath> My reasoning for that is mail is pretty important and by using sqlite we're removing a dependancy. 15:22 then copy everything into fedora-config 15:23 mmcgrath, mail is important, I know mysql works, I haven't tried sqlite myself yet 15:23 <@mmcgrath> if you run into any issues or concerns send a note to the list and we'll just use MySQL. 15:23 ok 15:24 -!- mmcgrath changed the topic of #fedora-admin to: config management 15:24  * dgilmore needs f13's cloning machine 15:24 btw, what URL is EPEL at now? 15:24 warren: there is none 15:24 <@mmcgrath> http://fedoraproject.org/wiki/EnterpriseExtras 15:24 whats built is on the buildsys 15:24 smtp is not using EPEL packages? 15:24 even pre-EPEL 15:24 warren: smtp is fc-6 15:24 oh 15:24 that makes it easy =) 15:25 migrating that to RHEL5 + EPEL later will be easy 15:25 <@mmcgrath> So a little discussion has taken place, I just keep putting it off. Mostly because we have a system in place that sort of works. 15:25 damnit. 15:25 <@mmcgrath> regarding config management 15:25 I got distracted again. Shiney new hardware in my cube 15:25 <@mmcgrath> f13: ?? 15:25 <@mmcgrath> hah! 15:25 the schema can probably come as soon as we get the legal audit done 15:25 which should be end of this week~ 15:25 <@mmcgrath> so anyway, feel free to respond to symerian's email I'll be taking it all into account. 15:26 <@mmcgrath> f13: cool 15:26 -!- mmcgrath changed the topic of #fedora-admin to: Metrics 15:26 i've been using puppet for a while now and even though it's in ruby it's pretty awesome 15:26 <@mmcgrath> I've got smolt up and ready for review. jcollie has assigned it to himself. i'm hoping to have it in soon :-D 15:26 posted the review just before the meeting :) 15:27 <@mmcgrath> I've contacted the https://hosted.fedoraproject.org/projects/LHCP people but haven't heard back yet (it'd be nice if we can work together, our projects sound similar) 15:27 <@mmcgrath> jcollie: and I've already posted a patch :D 15:27 -!- mmcgrath changed the topic of #fedora-admin to: Caching Proxies 15:27 <@mmcgrath> kim0: anything to add? 15:27 <@mmcgrath> AFAIK thats on hold till the next version of the wiki comes out. 15:28 yeah ... 15:28 nothing from my side 15:28 <@mmcgrath> Can you ad a line item to the schedule under priority 1 for upgrading the wiki and put you or paulo in charge of it? 15:28 sure 15:28 <@mmcgrath> danke 15:29 <@mmcgrath> go ahead and move the caching proxies to priority 3 untill the next version comes out 15:29 okie too 15:29 <@mmcgrath> mdomsch: not here. 15:29 -!- mmcgrath changed the topic of #fedora-admin to: Yum Delta RPM 15:29 <@mmcgrath> kim0: so you've sparked quite a discussion, its ounds like a lot of work. 15:30 yeah big discussion ... 15:30 I've done some basic cli tools testing 15:30 seems to work fine 15:30 I'm seriously in the camp of -ENOTIMEFORF7 -> PUNTFORF8 15:30 detect damaged files and refuses to contrust new rpms 15:31 kim0, then fallback automatically to the full RPM download? 15:31 and can detect damages using only header (doesnt download drpm until afterwards) 15:31 warren: that's the plan, no code yet 15:31 my python coding skill basically suck .. so I am fighting 15:31 kim0, generally, we don't have time to help, but if you construct a working proof-of-concept that Just Works smoothly, others might join and rewrite it to be cleaner code. 15:32 how about writing the server side as a shell script ? 15:32 <@mmcgrath> kim0: I think warren's right. You're on your own until you get it working :-) 15:32 kim0: Can we proof of concept this outside of the master repository or do you need to upload drpms there? 15:32 kim0, and theoretically, delta rpm plugin and server side need not be an official thing of the project. Somebody can install the optional plugin and try it. 15:32 abadger1999: I think it can be anywhere 15:32 kim0, I don't think generating on-the-fly is the right approach to this. 15:33 warren: me too 15:33 no 15:33 <@mmcgrath> the mirrors won't support it. 15:33 warren: +1 15:33 it has to exist on OUR mirror and simply rsync it out to others 15:33 <@mmcgrath> remember that whatever goes out to the mirrors has to be static. 15:33 that is a hard requirement. 15:33 f13: yes that's exactly the plan 15:33 <@mmcgrath> k 15:33 check out the wiki page 15:33 generate common upgrade paths, analyze if it is worthwhile to keep it as a delta (>1MB and 80% download savings), etc. 15:33 warren: yep +1 too 15:34 Then put those files in some directory to be mirrored 15:34 kim0, during the concept testing phase, it could be a side project with optional plugin 15:34 kim0, don't wait on us to provide any server resources or to put it on mirrors 15:35 sounds fine 15:35 although... you would need somewhere to put the concept delta data 15:35 do you need webspace or something? 15:35 not now, I have to get something working first 15:35 did you write all requirements on a wiki page? 15:35 that's a good first step 15:36 yeah .. basically the briefing from all email discussions 15:36 about creating server side metadata 15:36 do u guys think we should modify createrepo s skvidalsuggests 15:37 coz u said, we need to keep this out of the way 15:37 so maybe this should be a standalone script ? 15:37 I dunno yet... I am not sure createrepo needs to be involved 15:37 I might be missing some aspect of this. 15:37 It could be handled the same as comps.xml is now. 15:37 yum thinks "I have foo-1.0-1" 15:37 yum thinks "I want foo-1.0-2" 15:37 createrepo has a '-g' command line switch to link in a pregenerated comps.xml file in the proper location. 15:38 abadger1999: looks good 15:38 how is this relevant? 15:38 So you have an external tool that creates the drpm metadata. Then you have a switch in createrepo that links that in. 15:38 cool .. so I can generate the XML file on myown 15:39 Later, when drpm is accepted as a good thing, the code gets merged into createrepo if it makes sense. 15:39 abadger1999: and yum on client side, will be downloading that XML too, right ? 15:39 I'm still failing to see how this helps at all. 15:39 yum thinks "I want foo-1.0-2". yum delta rpm plugin thinks "Is there a delta available?" 15:40 You're saying createrepo could generate delta metadata too? 15:40 not currently 15:40 Is this what is suggested? 15:40 I don't know for sure, but I think yum downloads repomd.xml (with the link to the drpm metadata) then the drpm plugin retrieves the file based on the repomd.xml link. 15:40 warren: skvidal seemed to suggest that, yes. 15:40 oh, ok 15:41 that's the cleaner invasive solution I guess 15:41 Then, you need three pieces 15:41 1) delta generator, which is intelligent in which to keep, which to throw away 15:41 but I guess at first I will keep it as external 15:41 2) createrepo that knows about deltas 15:41 3) yum plugin that reconstitutes the original RPM 15:41 2 => is not needed ? 15:41 is deltarpm 3.3 the latest version? and is it packaged for FC6 yet? 15:42 warren: -g will just link in the new xml file 15:42 <@mmcgrath> we should probably discuss technical implementations of deltarpm after the meeting (which should end in about 5 minutes) can we put it off till then? 15:42 kim0, not strictly needed, but as a final implementation it would be smooth that way. 15:42 I think we're done. 15:42 ok .. I'm done 15:42 kim0, write all this down on a wiki page. 15:43 <@mmcgrath> k, so thats all the priority 1 and 2 stuff.. 15:43 okie 15:43 -!- mmcgrath changed the topic of #fedora-admin to: Open Floor 15:43 <@mmcgrath> Anyone got anything before we close the meeting? 15:43 not i 15:43 < daMaestro> what is expected of my xen instance? 15:44 if anyone wants to get deltarpm-python in extras, it would be helpful :) 15:44 < daMaestro> what am i supposed to be getting running? 15:44 <@mmcgrath> Fill out the information in that RFR form I linked to. 15:44 < daMaestro> ok 15:44 f13: Some of FESCo were surprised that we would be switching to brew for F7. 15:45 <@mmcgrath> Was this the first they'd heard of it? 15:45 In a way. 15:45 <@mmcgrath> does brew still rely on mock? 15:45 we had to be some what quiet 15:45 tibbs said that we'd talked about it being open sourced but not that we were going to switch 15:45 * mmcgrath knows almost nothing about brew. 15:45 mmcgrath: yes. 15:45 <@mmcgrath> So in the end there's very little chance that the actual RPM's will be different whether built with plague or brew, right? 15:46 abadger1999: yeah, we weren't sure if it was going to be OSS'd, but since it is going to be, the people doing the work really want to go with brew 15:46 mmcgrath: pretty much 15:46 <@mmcgrath> k. 15:46 Who's doing the work, though. 15:47 The Monday meeting was the first time I heard that Jeremy's working on it, for instance. 15:49 I'm more concerned that things I'm working on wrt the packagedb aren't worthwhile because I don't know if people are working on enabling the same things for brew. 15:49 For instance. 15:49 abadger1999: I suspect it will be a combination of some of the original Brew authors, Jeremy, Bill, myself, anybody from the commuinty that is interested, etc... 15:49 kim0: is there an url for deltarpm-python? 15:49 abadger1999: We're going to have a bit of a hack session at fudcon. Are you coming to fudcon? 15:49 japj: http://people.redhat.com/~herrmann/deltarpm/deltarpm-python/ 15:49 Yep. I'll be there :-) 15:50 Splitting time between several groups :-( 15:50 * jcollie is sad because I can't come to FUDcon 15:50 abadger1999: yeah, I will be too 15:50 <@mmcgrath> we'll discuss this more at FUDCon and get the details irned out. 15:50 < daMaestro> mmcgrath, thanks for the note +1 15:50 Mike M, one of the main authors of brew will be there too 15:50 ok, I have to go away and concentrate for a bit 15:50 < daMaestro> f13, put me down for the brew session :-P 15:51 * mmcgrath not Mike M, but is Mike M :-D 15:51 f13: And a code drop is looking hopeful for the end of this week? 15:51 <@mmcgrath> ok. If no one has anything else I'll close the meeting and we can continue to discuss delta-rpm 15:51 <@mmcgrath> 10 15:51 <@mmcgrath> 0 15:51 <@mmcgrath> - MEETING END --