Infratructure Meeting Log for 2007/08/23

[Jeffrey C. Ollie]

[15:02] mmcgrath has set the subject to Infrastructure -- Role call
[15:02] mmcgrath: Who's here?
[15:02] * lmacken 
[15:02] jeremy has left (Remote closed the connection (i=ikatzj at nat/redhat/x-85aceb302d31e828))
[15:02] warren has left (Remote closed the connection (i=warren at redhat/wombat/warren))
[15:02] * ricky 
[15:02] paulobanon: pong
[15:02] * londo is here
[15:02] * yingbull is here
[15:02] mmcgrath: crazy, that happened at this same time last week (jeremy and warren logging off right as the meeting started.
[15:03] * ricky is.
[15:03] paulobanon: yup
[15:03] abadger1999: yes
[15:04] mmcgrath has set the subject to Infrastructure -- Tickets
[15:04] mmcgrath: https://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority
[15:04] mmcgrath: paulobanon: Ticket #52, whats up?
[15:04] paulobanon: k so
[15:04] paulobanon: im going with mod_cache all the way for now
[15:04] jcollie: oops i'm here
[15:05] paulobanon: we are currently using mod_cache_disk and _mem
[15:05] paulobanon: and hopefully during the weekend or early next week start stress testing
[15:05] paulobanon: and see what is improved, and what can be improved
[15:05] paulobanon: thats it
[15:05] mmcgrath: Cool, good to hear thats still making progress.  Will we be able to implement for Fedora 8?
[15:06] paulobanon: YUP
[15:06] paulobanon: 
[15:06] mmcgrath: fantastic
[15:06] paulobanon: thats the plan
[15:06] mmcgrath: cool, anything else or we'll move on.
[15:06] jeremy has joined the group chat (i=katzj at nat/redhat/x-6c63cab4c75caa85)
[15:06] paulobanon: move one 
[15:06] mmcgrath: k
[15:07] mmcgrath: ticket #14 - Choose New VCS for Packages
[15:07] mmcgrath: jcollie: any word?
[15:07] jcollie: nope... semester starts next week 
[15:08] mmcgrath: k, no worries.  We'll move on.
[15:08] mmcgrath: ticket #31 - The wiki
[15:08] * ricky doesn't have much to say about the wiki either 
[15:08] mmcgrath: ricky: should we remove the meeting notice on that ticket?
[15:08] stahnma: I added a thought on the ticket
[15:08] stahnma: but, it doesn't change the status
[15:08] stahnma: 
[15:08] ricky: mmcgrath: Sure, I hope to be working on FAS2 for a while :
[15:08] ricky: **
[15:09] mmcgrath: stahnma: feel free to talk about it.  your concern was that we not automatically disclude PHP based wikis right?
[15:09] stahnma: yes
[15:09] abadger1999: yay!
[15:09] paulobanon: \o/
[15:09] abadger1999: Err... Not pp
[15:09] abadger1999: php
[15:09] abadger1999:  
[15:09] stahnma: I just think that autocutting PHP is a bit short-sited
[15:09] stahnma: it might not make it for other reasons
[15:09] stahnma: but security for PHP is more of a rep basedon PHP apps, not PHP itself
[15:09] stahnma: yes, it's very easy to code bad php
[15:10] mmcgrath: One thing to keep in mind is that we don't have php anywhere else (or java for that matter) so it does make them less attractive.
[15:10] stahnma: true
[15:10] stahnma: that's a valid point
[15:10] * ricky mentions cacti, just to be evil 
[15:10] mmcgrath: ricky: actually thats a good point.
[15:10] mmcgrath: Though its on our noc machine 
[15:10] stahnma: it's also esy to write good PHP, if you try
[15:10] stahnma: and I think mediawiki is awesome
[15:10] stahnma: and secure...as secure as a wiki can be
[15:10] * stahnma is done onthat one 
[15:11] mmcgrath: the other thing with the wiki is that its been taking a lower priority as of late.
[15:11] paulobanon: lots of ppl working on other stuff
[15:11] mmcgrath: stahnma: if you are interested feel free to review other wikis (and how to migrate from moin to them) post to the list.
[15:11] abadger1999: stahnma: I'm not sure I'd agree with that.  Look at the cve's for mediawiki, for instance.
[15:11] paulobanon: and as a future moin is adding a DB backend also
[15:11] ricky: Cool!
[15:11] stahnma: abadger1999: fair enough, I am not all that educated on it ....
[15:12] mmcgrath: ricky: mind if I remove the "meeting" tag from that ticket?
[15:12] * paulobanon suggests adding it to FAS2 
[15:12] mmcgrath: paulobanon: <nod> I'll do that now since its getting to crunch time.
[15:12] * paulobanon is evil now... and run from ricky
[15:12] ricky: mmcgrath: Sure.
[15:13] mmcgrath: lets talk about that now actually
[15:13] mmcgrath: Ticket #9 - Fedora Accounts System (LDAP)
[15:13] mmcgrath: I know ricky has been doing a ton of work on it, whats the latest?
[15:14] * paulobanon crashes lots of stuff...
[15:14] ricky: Well my only change to the LDAP schema was to add a description field for groups- everything else was with the TG app.
[15:14] paulobanon: ricky: u're using genshi or kid ?
[15:14] ricky: I ended up moving the user/group sections out into different files/switching to genshi and doing some general template cleanups.
[15:14] jcollie: didn't we need something for UIDs/GIDs?
[15:15] abadger1999: Cool.  So lots of cleanup it sounds like.
[15:15] mmcgrath: jcollie: yeah we still need to add UIDs and GIDs, there's a way in ldap to do that and ensure its unique but I didn't get it working.
[15:15] ricky: Hopefully, the permissions stuff should all be separated into auth.py now, although the templates still need to be made to use it.
[15:15] mmcgrath: lots of *much needed* cleanup 
[15:16] ricky: But I have a feeling that the next cleanup will probably need to remove some really inefficient LDAP queries that I used- heh/
[15:16] mmcgrath: ricky: what are your near future plans with it?  Do you want to take ownership over this and make sure its done by F8 or would you rather just hack on it and get more stuff done?
[15:16] mmcgrath: we can always do that down the road, I've seen what your queries are doing and they feel reasonably fast (though you're right, they probably won't scale very well)
[15:17] ricky: mmcgrath: Well, my plan is to concentrate on mostly on FAS, but it'd be great to have more people that actualyl know python work on it 
[15:17] paulobanon: is FAS2 still up for F8 release ?
[15:17] ricky: (This is really my first time touching python/TG)
[15:18] ricky: paulobanon: That might depend on the criteria.
[15:18] mmcgrath: paulobanon: I'm hoping so though it dawned on me that releasing it close to the GA release may not be a good idea.
[15:18] ricky: paulobanon: I've heard something about possible OpenID integration, etc. so I'm not sure how "featureful" it needs to be by release.
[15:18] mmcgrath: so I'd like to have it ready for F8, but then deploy it shortly after.
[15:18] mmcgrath: <nod> we're shooting for OpenID integration but not for the initial rollout.
[15:18] ricky: Ah, that makes it more realistic 
[15:18] mmcgrath: right now we just want to replace whats there with this, then add on to it.
[15:19] daMaestro has joined the group chat (n=jon at fedora/damaestro)
[15:19] ricky: Oh, then the big missing stuff is editing groups, CLA, and integration with other apps, shell accounts, etc.
[15:19] ricky: (And maybe a good lookover for any security issues for good measure)
[15:19] ChitleshGoorah has left (Remote closed the connection (n=chitlesh at fedora/ChitleshGoorah))
[15:20] mmcgrath: <nod> CLA (hopefully through a wizzard) and the integration with other apps.
[15:20] abadger1999: Do we have a spec on the new CLA process?
[15:20] * skvidal hates at the CLA
[15:20] ricky: Hm, would it necessarily have to be an e-mail process, since we'd already have the e-mail linked to the user?
[15:20] mmcgrath: For the initial rollout I'll probably leave the clients alone.
[15:20] abadger1999: Still gpg signed, but via a web form?
[15:20] ricky: abadger1999: +1
[15:20] mmcgrath: abadger1999: its going to duplicate what is there now, but through a web form instead of email.
[15:21] abadger1999: Sounds good.
[15:21] ricky: And as a TODO, when the user changes their e-mail it should be verified before the change is accepted.
[15:21] mmcgrath: and hopefully with proper debugging (IE: Your key is not found on MIT's site, you didn't encrypt this, this isn't the cla) that sort of thing.
[15:21] ricky: I'm not sure how we'd implement that within our current LDAP schema.
[15:21] abadger1999: mmcgrath: +1
[15:21] abadger1999: mmcgrath: Almost certainly, translations of the CLA would have to pass legal.
[15:22] abadger1999: ricky: We'll have to put that in the DB
[15:22] mmcgrath: abadger1999: <nod> I'll muse about that for a while.  That won't be in the intitial rollout.
[15:22] abadger1999: ricky: A queuing system of some sort.  LDAPusername wants to use newemail at ....
[15:22] mmcgrath: we'll have to discuss that further.  probably on the mailing list.
[15:22] ricky: abadger1999: Ah, so some DB integration for purely internal accounts system stuff.
[15:23] ricky: That sounds like it'd help a lot- I wouldn't feel so locked into to the LDAP schema.
[15:23] abadger1999: ricky: When the user replies, the TG app looks in the queue, changes it in LDAP and removes it from the queue.
[15:23] abadger1999: ricky: 
[15:23] mmcgrath: ricky: anything else with FAS2?  If not we'll move on.
[15:23] paulobanon: go go go go go
[15:24] ricky: mmcgrath: Everything sounds good for now- I'll probably ask more questions in #fedora-admin later.
[15:24] mmcgrath: cool, thanks for working on this.  Seems every time I sat down to work on it, something else came up.
[15:24] mmcgrath has set the subject to Infrastructure -- Schedule
[15:24] mmcgrath: http://fedoraproject.org/wiki/Infrastructure/Schedule
[15:24] kital has joined the group chat (n=Joerg_Si at fedora/kital)
[15:25] mmcgrath: I need to update the schedule.  I think the sponsorship setup we have now is good though we need to let it run its course and get more people involved.
[15:25] mmcgrath: we talked about VCS already.
[15:25] mmcgrath: Does anyone have anything to say about the SOP's?
[15:25] mmcgrath: We don't have that many yet.
[15:25] paulobanon: if we have people asking new hosted project
[15:25] mmcgrath: The ones we do have are pretty good though.
[15:25] paulobanon: whats the rule on that
[15:26] mmcgrath: Thats a good question, and its kind of up in the air.
[15:26] mmcgrath: The problem is, and I'll be blunt, we don't want to host crap.
[15:26] paulobanon: +1
[15:26] ricky: Hm, I wonder if some of the longer ones could be made into scripts.
[15:26] mmcgrath: but without knowing the people and projects involved.  Its hard to figure out whats crap and whats gold.
[15:26] mmcgrath: ricky: ?
[15:26] mmcgrath: you mean the longer instructions in the SOP?
[15:27] paulobanon: so i would say mail the list and explain what/why and request approval
[15:27] ricky: Actually, I guess this only applies to the denyhosts one, never mind 
[15:27] mmcgrath: maybe.  Actually you should mail the list and we should discuss it more.
[15:27] mmcgrath: 
[15:27] paulobanon: i agree
[15:28] paulobanon: right now, anyone that wants it, goes to trac, open a ticket and assign it to f13
[15:28] mmcgrath: Yep.
[15:28] mmcgrath: thats the current process though I don't think f13 (or anyone else really) wants f13 to have to do all of that.  It just keeps growing.
[15:28] paulobanon: yup
[15:28] mmcgrath: paulobanon: email after the meeting and we'll make sure to comment on it.
[15:29] paulobanon: k k
[15:29] mmcgrath: anyone else have anything on the schedules page?  If not we'll move on
[15:29] paulobanon: im good
[15:30] mmcgrath: cool.
[15:30] mmcgrath has set the subject to Infrastructure -- Puppet Training
[15:30] * paulobanon wants more then puppet training 
[15:30] mmcgrath: Just a reminder, we have puppet training on Monday at 20:00 UTC.
[15:30] mmcgrath: that seems to have worked out for most people (I know jima had a conflict)
[15:31] mmcgrath: If this goes well hopefully we'll be able to figure out other training sessions (like for pkgdb or even the packaging process in general from time to time)
[15:31] paulobanon: i can pretty much everyday after 19UTC
[15:31] ricky: Do any of the Asterisk experts have any thoughts on recording it?  
[15:31] mmcgrath: we'll see.  I've had a lot of positive comments about the fact that we're even doing training so perhaps I'm on to something here 
[15:31] mmcgrath: ricky: good question
[15:32] mmcgrath: AFAIK, we've had a few people look at it, but no one's gotten it to work right yet.
[15:32] mmcgrath: I'll try to take a closer look before the training.
[15:33] ricky: mmcgrath: I think tested something similar using Monitor a while ago.
[15:33] mmcgrath: <nod> how well did it work for you?
[15:33] paulobanon: i wasnt here for Vfudcon, was it nice using asterisk, and considered a success ?
[15:33] ricky: Hm..  I know it was easy to setup, but I don't even remember how the voice quality was.
[15:33] mmcgrath: paulobanon: not that many people used it but of those that did I think people liked it.
[15:34] paulobanon: cool cool
[15:34] mmcgrath: ricky: <nod> I guess we'll have to play around some.
[15:34] mmcgrath: ok, so thats all I have right now.
[15:34] mmcgrath has set the subject to Infrastructure -- Open Floor
[15:34] skvidal: anyone have any bright ideas for backups?
[15:34] mmcgrath: other then backups are a bright idea, no 
[15:34] skvidal: for fedorapeople.org
[15:34] skvidal: I mean
[15:35] skvidal: sorry
[15:35] paulobanon: im the backup guy in my company, but its not opensource
[15:35] mdomsch: SLA == no backups?
[15:35] skvidal: paulobanon: yah, we'd like open, thanks
[15:35] paulobanon: doesnt bacula owrks for u skvidal ?
[15:35] paulobanon: (works
[15:36] mmcgrath: mdomsch: well, there's a couple of problems going on, bacula doesn't work very well behind a NAT.
[15:36] londo: I am happy with rdiff-backup to a different disk for a similar local system
[15:36] skvidal: need something to put the data on
[15:36] mmcgrath: and we're running out of storage.
[15:36] skvidal: and as mmcgrath said
[15:36] mmcgrath: right now we're doing a nightly rsync.
[15:36] skvidal: bacula and the firewall is sub-optimal
[15:36] paulobanon: mmcgrath: can that be requestsed from the budget? a mini storage/robot for backups ?
[15:37] mmcgrath: paulobanon: we're looking at different options right now including rsync.net, s3 and a few others
[15:37] ricky: Hehe.
[15:38] mmcgrath: I'm looking at costs of hosting our backups off site or on site.
[15:38] mmcgrath: our options are many but some may just not work out.
[15:39] skvidal: 
[15:39] mmcgrath: I'll take that as a no for right now.
[15:39] mmcgrath: mdomsch: whats the most amount of storage we could get in a 2U from dell right now?
[15:40] paulobanon: u want to offsite data in what format ? tapes or backup to an external source ?
[15:40] yingbull: mmcgrath: I'd need to know requirements and constraints before I could give useful input on backups.
[15:40] yingbull: mmcgrath: we might want to define those first.
[15:40] caillon has left ( (n=caillon at mithril.returnzero.com))
[15:41] mmcgrath: 2T worth of RPMs and 1T worth of other data.
[15:41] mmcgrath: The largest restore we'd have (right now) is the 2T worth, hopefully it could be done in a matter of a day or two.
[15:41] mmcgrath: using rsync.net under my last estimations, would take about 13 days.
[15:41] yingbull: mmcgrath: Length of retention?
[15:42] paulobanon: why not buy an LTO3 robot, and just offsite the tapes ?
[15:42] mmcgrath: that actually includes the retentions.
[15:42] mmcgrath: paulobanon: we don't have a person at the colo.
[15:42] skvidal: paulobanon: b/c we lack the facilities for it
[15:42] mmcgrath: and we don't have space for it.
[15:42] paulobanon: i dont have persons in 5 of my colos
[15:42] paulobanon: and i still do it 
[15:42] mmcgrath: 
[15:42] skvidal: paulobanon: but I'm guessing you have power 
[15:42] skvidal: paulobanon: and rack space
[15:43] paulobanon: we have space yes
[15:43] mmcgrath: thats the other part of this whole mess is trying to figure out whats going in our current colo and what might end up in the new colo.
[15:43] paulobanon: 1 EML, doing 1.5T backups
[15:43] paulobanon: per colo
[15:44] skvidal: paulobanon: how long do you keep your tapes in rotation?
[15:44] paulobanon: depends
[15:44] mmcgrath: and how much did the tapes + robot cost?
[15:44] skvidal: mmcgrath: 24 tape changer from dell for lto3 is $7K
[15:44] paulobanon: auth 1year, normal game dbs 7days
[15:44] mmcgrath: skvidal: +tapes?
[15:44] skvidal: tapes are $70 or so each for a 400GB tape
[15:45] paulobanon: skvidal: LTO3 i hope
[15:45] yingbull: skvidal: that includes the drive too?
[15:45] skvidal: and you need a box that drives them of course
[15:45] skvidal: paulobanon: yes
[15:45] skvidal: yingbull: last time I checked, yes
[15:45] paulobanon: skvidal: check out recall
[15:45] * mmcgrath goes on the record saying he hates tapes.
[15:45] paulobanon: its what we use to offsite
[15:45] paulobanon: they pickup and drop everything
[15:46] Renault has joined the group chat (n=couretca at AToulon-151-1-34-26.w83-205.abo.wanadoo.fr)
[15:46] paulobanon: u just need to have someone to get the tapes in the container
[15:46] yingbull: Tapes are useful for offsite.  Disk is useful for quick restores.
[15:46] mmcgrath: paulobanon: we don't have that though 
[15:46] mmcgrath: well there's two sides to this.  1) DR and 2) backups.
[15:46] mmcgrath: we're just focusing on backups right now.  DR is later.
[15:46] yingbull: raided SATA disks, that get offsited over the net for extra recovery wouldn't be bad.
[15:47] yingbull: That way you've got local restores, but you can rsync/other methods to an offsite location that does have tapes, or another backup system.
[15:47] ricky: Wait, what's the current backup situation?
[15:47] yingbull: ricky: good question.
[15:47] mmcgrath: ricky: we're backing up everything except the koji share.
[15:47] mmcgrath: using bacula.  with 2 week retention.
[15:48] ricky: Ah.
[15:48] tibbs has left ("Konversation terminated!" (n=tibbs at fedora/tibbs))
[15:48] paulobanon: mmcgrath: how many cycles ?
[15:48] mmcgrath: one full every sunday, incrementals every day.
[15:48] paulobanon: so 15/2
[15:48] paulobanon: 15 days / 2 cycles
[15:48] mmcgrath: yep
[15:50] mmcgrath: The tricky part is funding (we're still working on that in the background)
[15:50] mmcgrath: If fedora ends up getting a regular actual IT budget, some of these problems will solve themselves.
[15:51] mmcgrath: I'll take the silence as a general "move on" 
[15:51] paulobanon: 
[15:51] mmcgrath: anyone have anything else they'd like to discuss?
[15:51] paulobanon: when should we start preparing the plan of action for F8
[15:51] paulobanon: better safe then sorry
[15:51] paulobanon: not too safe though 
[15:51] mmcgrath: There are some things we can do now, but in general I've created all the tickets that need to be created.  By the final test release we should have most of the website ready at http://fedoraproject.org/_/
[15:52] mmcgrath: then its just a matter of making sure the open tickets for Fedora 8 get done and or moved.
[15:52] skvidal: and I should have a listof where everything is
[15:52] skvidal: b/c while mike is off gallivanting around on his honeymoon
[15:52] skvidal: some of us will be here working
[15:52] * mmcgrath can't wait.
[15:52] paulobanon: lol
[15:52] ricky: Hehe- congrats, by the way 
[15:52] mmcgrath: just a reminder - http://fedoraproject.org/wiki/Infrastructure/SOP/Release
[15:52] mmcgrath: thanks 
[15:53] paulobanon: take us with u!!
[15:53] mmcgrath: and all of those tickets have been created here somewhere - https://hosted.fedoraproject.org/projects/fedora-infrastructure/report/1
[15:53] mmcgrath: I'll ask the future Mrs. mmcgrath.
[15:53] paulobanon: 
[15:55] mmcgrath: Ok, if no one has anything else I'll close the meeting in 30
[15:55] mmcgrath: 15
[15:55] yingbull: I'll just add I'm back from $DAYJOB travel and will be nosing around for work.
[15:55] mmcgrath: yingbull: excellent
[15:55] mmcgrath: Ok, meeting closed
[15:56] mmcgrath has set the subject to Meeting End
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20070823/c9f98377/attachment.bin