Infrastructure/Meetings/2007-01-18

Meeting of 2007-01-18

*** Time shown in EST

14:59 <@mmcgrath> Meeting!  You guys about ready?
14:59 < jcollie> aye aye captain!!!
15:02 <@mmcgrath> abadger1999, warren, skvidal, iWolf, dgilmore, f13, kim0: ping
15:02 < abadger1999> pong
15:02 <@mmcgrath> role call!  who's here?
15:02 < kim0> here
15:02 -!- mmcgrath changed the topic of #fedora-admin to: meeting in progress
15:02 < skvidal> I'm in a meeting
15:02 < skvidal> so I'll be slow to respond
15:02 <@mmcgrath> skvidal: This meeting!
15:02 <@mmcgrath> :-)
15:02 < skvidal> no, another one
15:02 < skvidal> sorry
15:02  * dgilmore is here
15:02 < skvidal> :)
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 < jcollie> 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 < dgilmore> mmcgrath: i had a quick look at it
15:04 < dgilmore> it looks pretty good
15:04 < kim0> looks good to me
15:04 -!- lyz [n=lyz@dsl081-149-006.chi1.dsl.speakeasy.net]  has joined #fedora-admin
15:05 < abadger1999> Would be good to have a list of the open RFRs
15:05 < abadger1999> Otherwise looks good.
15:05 < warren> one thought regarding the Template
15:05 < warren> 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 < warren> 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 < jcollie> 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 < dgilmore> :)
15:09 < jcollie> abadger1999, using categories would make it easy to track RFRs
15:09 <@mmcgrath> ok, on to the schedule.
15:09 < dgilmore> mmcgrath: we need to make sure the publictest instances are approved
15:09 < dgilmore> the only one i know we did discuss was f13's hosted
15:09 < abadger1999> And f13's hgtest
15:09 <@mmcgrath> dgilmore: hmmm, we can do that.
15:10 < dgilmore> 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 < dgilmore> though AFAIKT  the ones that are up all look fine
15:10  * mmcgrath forgot
15:10 < f13> crap, I forgot about this meeting.
15:10 < f13> again.
15:10 < f13> 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 < abadger1999> I've got a TG identity and visit plugin :-)
15:12 < abadger1999> It ties into our present FAS.
15:12 <@mmcgrath> very nice
15:12 < abadger1999> It's for sqlalchemy so I have to test it with lmacken's code as well.
15:12 < abadger1999> (of someone else using sqlobject)
15:13 < abadger1999> 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 < warren> f13, btw, is the brew schema coming sooner, or brew itself is coming soon?
15:13 < abadger1999> Did anyone look at: http://www.fedoraproject.org/wiki/Infrastructure/AccountSystem2/API
15:14 < abadger1999> 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 < abadger1999> mmcgrath: It's a bit hard for me to say as I don't know LDAP too well :-(
15:15 < abadger1999> I glanced at the python-ldap docs this weekend
15:15 < abadger1999> And I think things will map okay.
15:15 < warren> 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 < abadger1999> But my ignorance of LDAP shows.
15:15 <@mmcgrath> abadger1999: we can focus on that during FUDCon
15:15 < abadger1999> warren: Not really.
15:16 < abadger1999> This is the fourth project I've worked on that uses fas and I just got tired of using website.py
15:16 < abadger1999> 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 < abadger1999> daMaestro: That would be appreciated.
15:18 < abadger1999> 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 < dgilmore> 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 < abadger1999> 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 < warren> mmcgrath, I'm in the process of upgrading spamassassin for RHEL-4.5, right now actually
15:21 < warren> mmcgrath, that should be the last piece
15:22 < warren> 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 < warren> OK, I'll reconfigure that.
15:22 < dgilmore> warren: i didnt get a chance to change it :(
15:22 < warren> 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 < warren> then copy everything into fedora-config
15:23 < warren> mmcgrath, mail is important, I know mysql works, I haven't tried sqlite myself yet
15:23 <@mmcgrath> <nod>  if you run into any issues or concerns send a note to the list and we'll just use MySQL.
15:23 < warren> ok
15:24 -!- mmcgrath changed the topic of #fedora-admin to: config management
15:24  * dgilmore needs f13's cloning machine
15:24 < warren> btw, what URL is EPEL at now?
15:24 < dgilmore> warren: there is none
15:24 <@mmcgrath> http://fedoraproject.org/wiki/EnterpriseExtras
15:24 < dgilmore> whats built is on the buildsys
15:24 < warren> smtp is not using EPEL packages?
15:24 < warren> even pre-EPEL
15:24 < dgilmore> warren: smtp is fc-6
15:24 < warren> oh
15:24 < warren> that makes it easy =)
15:25 < warren> 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 < f13> damnit.
15:25 <@mmcgrath> regarding config management
15:25 < f13> I got distracted again. Shiney new hardware in my cube
15:25 <@mmcgrath> f13: ??
15:25 <@mmcgrath> hah!
15:25 < f13> the schema can probably come as soon as we get the legal audit done
15:25 < f13> 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 < jcollie> 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 < jcollie> 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 < kim0> yeah ...
15:28 < kim0> 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 < kim0> 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 < kim0> 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 < kim0> yeah big discussion ...
15:30 < kim0> I've done some basic cli tools testing
15:30 < kim0> seems to work fine
15:30 < f13> I'm seriously in the camp of -ENOTIMEFORF7 -> PUNTFORF8
15:30 < kim0> detect damaged files and refuses to contrust new rpms
15:31 < warren> kim0, then fallback automatically to the full RPM download?
15:31 < kim0> and can detect damages using only header (doesnt download drpm until afterwards)
15:31 < kim0> warren: that's the plan, no code yet
15:31 < kim0> my python coding skill basically suck .. so I am fighting
15:31 < warren> 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 < kim0> 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 < abadger1999> kim0: Can we proof of concept this outside of the master repository or do you need to upload drpms there?
15:32 < warren> 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 < kim0> abadger1999: I think it can be anywhere
15:32 < warren> kim0, I don't think generating on-the-fly is the right approach to this.
15:33 < kim0> warren: me too
15:33 < f13> no
15:33 <@mmcgrath> the mirrors won't support it.
15:33 < abadger1999> warren: +1
15:33 < f13> 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 < f13> that is a hard requirement.
15:33 < kim0> f13: yes that's exactly the plan
15:33 <@mmcgrath> k
15:33 < kim0> check out the wiki page
15:33 < warren> generate common upgrade paths, analyze if it is worthwhile to keep it as a delta (>1MB and 80% download savings), etc.
15:33 < kim0> warren: yep +1 too
15:34 < warren> Then put those files in some directory to be mirrored
15:34 < warren> kim0, during the concept testing phase, it could be a side project with optional plugin
15:34 < warren> kim0, don't wait on us to provide any server resources or to put it on mirrors
15:35 < kim0> sounds fine
15:35 < warren> although... you would need somewhere to put the concept delta data
15:35 < warren> do you need webspace or something?
15:35 < kim0> not now, I have to get something working first
15:35 < warren> did you write all requirements on a wiki page?
15:35 < warren> that's a good first step
15:36 < kim0> yeah .. basically the briefing from all email discussions
15:36 < kim0> about creating server side metadata
15:36 < kim0> do u guys think we should modify createrepo s skvidalsuggests
15:37 < kim0> coz u said, we need to keep this out of the way
15:37 < kim0> so maybe this should be a standalone script ?
15:37 < warren> I dunno yet... I am not sure createrepo needs to be involved
15:37 < warren> I might be missing some aspect of this.
15:37 < abadger1999> It could be handled the same as comps.xml is now.
15:37 < warren> yum thinks "I have foo-1.0-1"
15:37 < warren> yum thinks "I want foo-1.0-2"
15:37 < abadger1999> createrepo has a '-g' command line switch to link in a pregenerated comps.xml file in the proper location.
15:38 < kim0> abadger1999: looks good
15:38 < warren> how is this relevant?
15:38 < abadger1999> So you have an external tool that creates the drpm metadata.  Then you have a switch in createrepo that links that in.
15:38 < kim0> cool .. so I can generate the XML file on myown
15:39 < abadger1999> Later, when drpm is accepted as a good thing, the code gets merged into createrepo if it makes sense.
15:39 < kim0> abadger1999: and yum on client side, will be downloading that XML too, right ?
15:39 < warren> I'm still failing to see how this helps at all.
15:39 < warren> yum thinks "I want foo-1.0-2".  yum delta rpm plugin thinks "Is there a delta available?"
15:40 < warren> You're saying createrepo could generate delta metadata too?
15:40 < kim0> not currently
15:40 < warren> Is this what is suggested?
15:40 < abadger1999> 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 < abadger1999> warren: skvidal seemed to suggest that, yes.
15:40 < warren> oh, ok
15:41 < kim0> that's the cleaner invasive solution I guess
15:41 < warren> Then, you need three pieces
15:41 < warren> 1) delta generator, which is intelligent in which to keep, which to throw away
15:41 < kim0> but I guess at first I will keep it as external
15:41 < warren> 2) createrepo that knows about deltas
15:41 < warren> 3) yum plugin that reconstitutes the original RPM
15:41 < kim0> 2 => is not needed ?
15:41 < japj> is deltarpm 3.3 the latest version? and is it packaged for FC6 yet?
15:42 < kim0> 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 < warren> kim0, not strictly needed, but as a final implementation it would be smooth that way.
15:42 < warren> I think we're done.
15:42 < kim0> ok .. I'm done
15:42 < warren> kim0, write all this down on a wiki page.
15:43 <@mmcgrath> k, so thats all the priority 1 and 2 stuff..
15:43 < kim0> 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 < jcollie> not i
15:43 < daMaestro> what is expected of my xen instance?
15:44 < kim0> 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 < abadger1999> 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 < abadger1999> In a way.
15:45 <@mmcgrath> does brew still rely on mock?
15:45 < f13> we had to be some what quiet
15:45 < abadger1999> 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 < f13> 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 < f13> 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 < f13> mmcgrath: pretty much
15:46 <@mmcgrath> k.
15:46 < abadger1999> Who's doing the work, though.
15:47 < abadger1999> The Monday meeting was the first time I heard that Jeremy's working on it, for instance.
15:49 < abadger1999> 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 < abadger1999> For instance.
15:49 < f13> 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 < japj> kim0: is there an url for deltarpm-python?
15:49 < f13> abadger1999: We're going to have a bit of a hack session at fudcon.  Are you coming to fudcon?
15:49 < kim0> japj: http://people.redhat.com/~herrmann/deltarpm/deltarpm-python/
15:49 < abadger1999> Yep.  I'll be there :-)
15:50 < abadger1999> Splitting time between several groups :-(
15:50  * jcollie is sad because I can't come to FUDcon
15:50 < f13> 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 < f13> Mike M, one of the main authors of brew will be there too
15:50 < f13> 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 < abadger1999> 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  ----------------------