Meeting Log - 2010-02-04

[Ricky Zhou]

19:59 < mmcgrath> #startmeeting Infrastructure
19:59 < zodbot> Meeting started Thu Feb  4 20:01:09 2010 UTC.  The chair is mmcgrath. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59 -!- JSchmitt [~s4504kr at p4FDD0050.dip0.t-ipconnect.de] has joined #fedora-meeting
19:59 -!- JSchmitt [~s4504kr at p4FDD0050.dip0.t-ipconnect.de] has quit Changing host
19:59 -!- JSchmitt [~s4504kr at fedora/JSchmitt] has joined #fedora-meeting
19:59 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59 < mmcgrath> who's here?
19:59 -!- zodbot changed the topic of #fedora-meeting to:  (Meeting topic: Infrastructure)
19:59  * lmacken 
19:59 < Oxf13> I'm here, but distracted with lunch and another meeting
19:59  * jaxjax is here
19:59 < yawns1> here
19:59 < wzzrd> here
20:00 -!- sheid [U2FsdGVkX1 at weizentrinker.com] has joined #fedora-meeting
20:00  * dgilmore is present
20:00  * hiemanshu 
20:00  * skvidal is here
20:00  * nirik is around in the cheap seats. 
20:00 -!- a-k [~akistler at 2002:638e:1d25:3:20d:56ff:fe10:bb8d] has joined #fedora-meeting
20:00 < sheid> is here
20:00  * a-k is here
20:00 < mmcgrath> no one creates meeting tickets anymore so we can skip that :)
20:00  * abadger1999 here
20:00 < mmcgrath> #topic /mnt/koji
20:00 -!- zodbot changed the topic of #fedora-meeting to: /mnt/koji (Meeting topic: Infrastructure)
20:00 < mmcgrath> So I'm just making everyone aware what's going on here.
20:01 < mmcgrath> 1) we have a try'n buy from Dell on a equallogic
20:01 < mmcgrath> 2) /mnt/koji is 91% full
20:01 < mmcgrath> so we need to get cracking.
20:01 -!- mizmo [~duffy at fedora/mizmo] has joined #fedora-meeting
20:01 < mmcgrath> the equallogic is in a box in the colo so hopefully it won't take long.
20:01 < lmacken> I still have a script running from last night that is cleaning /mnt/koji/mash/updates
20:01 < mmcgrath> lmacken: oh that's good to know, any estimate on how much it'll clean up?
20:02 < lmacken> mmcgrath: I'm not quite sure...
20:02 < mmcgrath> <nod> no worries.
20:02 < lmacken> there are a *ton* of mashes to clean up
20:02 < Oxf13> hard to say with the hardlinks
20:02 < dgilmore> i expect little
20:02  * ricky is around
20:02 < dgilmore> since it should be mostly hardlinks
20:02 < mmcgrath> I'm *hoping* to have that thing installed and pingable by early next week.
20:02 < mmcgrath> the plan is going to be this.
20:02 < mmcgrath> once it's up and running I'm going to drop everything I'm doing and try to get it up and going.
20:02 < mmcgrath> dgilmore has promised a significant portion of his time as well.
20:02  * dgilmore will be focusing on it also 
20:03 < mmcgrath> we're going to be focusing on testing, speed, what works, virtualized,  unvirtualized, etc.
20:03 < mmcgrath> the equallogic will be exporting an iscsi interface, it's our job to figure out what to do with it.
20:03 < Oxf13> I've also promised some of my time to help generate traffic for testing
20:03 < mmcgrath> Oxf13: excellent
20:03 < mmcgrath> mdomsch: I know you enjoy the equallogics, do you have any interest in being involved in this?
20:04 < mdomsch> mmcgrath, I probably shouldn't, just so you feel it's a fair eval
20:04 < mdomsch> but if have questions, hit me and I'll try to help
20:04 < mmcgrath> mdomsch: fair enough :)
20:04 < mmcgrath> Ok, so that's really all I have on that for the moment, any other questions?
20:05  * mdomsch wants to bias the decision, but :-)
20:05 < mmcgrath> mdomsch: you just want to make it a 'n buy?  :)
20:05 -!- giarc [~cwt at 75.127.254.250] has joined #fedora-meeting
20:05 < mmcgrath> Ok, moving on.
20:05 < mmcgrath> #topic PHX2 network issues
20:05 -!- zodbot changed the topic of #fedora-meeting to: PHX2 network issues (Meeting topic: Infrastructure)
20:06 < mmcgrath> so there's been just a lot of strange things at the network layer in PHX2.
20:06 < mmcgrath> our data layer traffic has been fine so that's good.
20:06 < skvidal> mmcgrath: scooby doo sees odd things - phx2 is downright haunted
20:06 < mmcgrath> It seems much of that has been fixed at least as of right now.
20:06 < mmcgrath> skvidal: :)
20:06 < mmcgrath> Still, the way things are is just too bad for releng and QA to do their work
20:06 < smooge> here..
20:06 < mmcgrath> so I'm working on setting up alternate sites to grab their snapshots and test info.
20:07 < mmcgrath> one example is on sb1: http://serverbeach1.fedoraproject.org/pub/alt/stage/
20:07  * mmcgrath thanks the websites-team and likely ricky for getting that all properly branded.
20:07  * ricky passes the thanks onto sijis :-)
20:07 < mmcgrath> The good news is so far this setup hasn't required a change in releng's workflow.
20:08 < mmcgrath> the eh' news is that we haven't fully tested it yet but over time as people use it if it's working we'll keep it and/or add additional sites.
20:08 < mmcgrath> Any questions on that?
20:08 -!- iarlyy [~iarlyy at 189.90.160.121] has joined #fedora-meeting
20:08 < mmcgrath> alllrighty
20:08 < mmcgrath> #topic Fedora Search Engine
20:08 -!- zodbot changed the topic of #fedora-meeting to: Fedora Search Engine (Meeting topic: Infrastructure)
20:08 < mmcgrath> a-k: whats the latest?
20:09 < a-k> The news this week is that I've made Nutch available at
20:09 < a-k> #link http://publictest3.fedoraproject.org/nutch
20:09 < a-k> I intend to see how much both Xapian and Nutch can crawl before they break
20:09 < a-k> With Nutch, I expect the time it takes will just become unacceptable eventually
20:09 < a-k> Nutch takes longer than Xapian to crawl
20:09 < a-k> I still intend to keep looking for/at other candidates, too
20:09 < nirik> a-k: what content are you pointing it at right now?
20:09 < mmcgrath> Does Nutch make any smart decisions about crawling?
20:10 < a-k> I point both at just http://fedoraproject.org
20:10 < mmcgrath> a-k: FWIW, one of the test things I've been doing is searching for "UTC" I've found it's a good way to determine a good engine from a bad one on the wiki
20:10 < mmcgrath> for example:
20:10 < mmcgrath> https://fedoraproject.org/wiki/Special:Search?search=UTC&go=Go
20:10 -!- iarlyy [~iarlyy at 189.90.160.121] has left #fedora-meeting ["Leaving"]
20:10 < mmcgrath> CRAP
20:10 < a-k> mmcgrath: what do you mean by smart?
20:10 < mmcgrath> http://publictest3.fedoraproject.org/nutch/search.jsp?lang=en&query=UTC
20:10 < mmcgrath> not bad
20:10 < mmcgrath> well, nutch found the UTCHowto
20:11 < mmcgrath> instead of all the ones below it.
20:11  * mmcgrath just sayin.
20:11 < skvidal> cool
20:11 < a-k> It's important nor to confuse searching with indexing
20:11 < mmcgrath> a-k: how long are we talking about for crawling with nutch?
20:11 < nirik> a-k: you might also try meetbot.fedoraproject.org and see how it does with irc logs.
20:12 < a-k> Nutch crawled in about 16 hours what Xapian crawled in 8
20:12 < a-k> Neither crawls are the complete site yet
20:12 < mmcgrath> are there tunables?  is this as simple as 'add more processes' ?
20:13 < a-k> Nothing is especially tunable.  It might be limited by bandwicth.
20:13 < mmcgrath> yeah
20:13 < smooge> crawler needs more systems badly...
20:13 < nirik> don't shoot the url! ;)
20:13 < mmcgrath> 16 hours is a lot but might be acceptable.
20:14 < a-k> Although part of Nutch's problem could be an inherent inefficiecy in it's Java code
20:14 < a-k> Xapian is compiled C
20:14 < mmcgrath> a-k: what did we get with that 16 hours exactly?
20:14 < a-k> About 44k documents indexed
20:15 < mmcgrath> and Xapian crawled the same thing?
20:15 < a-k> Nutch and Xapian crawl differently
20:15 < mmcgrath> a-k: where was the Xapian url again?
20:16 < a-k> #link http://publictest3.fedoraproject.org/cgi-bin/omega
20:16 < a-k> As always, I keep notes on the wiki page
20:16 < a-k> #link http://fedoraproject.org/wiki/Infrastructure/Search
20:16 < abadger1999> a-k: You also had the unicode thing you posted in #fedora-admin
20:16 < abadger1999> Were you able to find a fix for that?
20:17 < a-k> No fixes.  Non-Latin characters hasn't really been something for which there's a requirement yet.
20:17 < a-k> I thought Nutch was a little funky with non-Latin characters, e.g., переводу, compared to Xapian
20:17 < a-k> But I've found Xapian examples that handle non-Latin just as bizarrely
20:17 < a-k> Neither Xapian nor Nutch claim to handle non-Latin characters
20:18 < a-k> We breifly mentioned non-Latin (non-UTF8) in a previous meeting
20:18 < abadger1999> <nod>
20:18 < a-k> Should there be a requirement around it?
20:19 < abadger1999> mmcgrath: What do you think?
20:19 < a-k> I suspect any requirement would eliminate ALL candidates
20:19 -!- jokajak [~jokajak at r83h51.res.gatech.edu] has joined #fedora-meeting
20:19 < abadger1999> We have a lot of non-native English users.
20:19 < mmcgrath> it probably should be a requirement.
20:20 < jaxjax> ññ
20:20 < mmcgrath> a-k: I'd think most engines have support for it, if not we should contact them and find out why
20:20 < a-k> A requiirement as opposed to something we take into consideration when choosing finally?
20:20 < smooge> actually its really really really slow to do non-ascii at times
20:21 < dgilmore> a-k: handling all languages should be a requirement
20:21 < a-k> Both seem to handle searching by expanding DBCS into hex
20:21 < a-k> Most of the time it seems to work
20:21 < a-k> Some of the time the results look screwed up
20:22 < a-k> Anyway I don't think I've got much more to add right now
20:23 < mmcgrath> a-k: thanks
20:23 < mmcgrath> We'll move on for now
20:23 < mmcgrath> a-k: try to find out what the language deal is
20:23 < smooge> a-k I remember old search engines had problems where language formats got combined on the same page.
20:23 -!- fbijlsma_ [~fbijlsma at p54B2C984.dip.t-dialin.net] has quit Quit: Leaving
20:23 < a-k> mmcgrath: ok
20:23 < mmcgrath> Anyone have anything else on that?
20:24 < mmcgrath> k
20:24 < mmcgrath> #topic Our 'cloud'
20:24 -!- zodbot changed the topic of #fedora-meeting to: Our 'cloud' (Meeting topic: Infrastructure)
20:24 < mmcgrath> so I'm trying to get our cloud hardware back in order.
20:24 < mmcgrath> I've been rebuilding the environment and getting it prepared for virt_web
20:24 < smooge> yeah
20:24 < mmcgrath> which should be at or near usable at this point.
20:24 < smooge> what can I do to help
20:24 < smooge> oh you already did it
20:24 < mmcgrath> smooge: not sure yet, we have a new volunteer working with me, sheid
20:24 < mmcgrath> and I'm sure SmootherFrOgZ as well.
20:24 < smooge> cool
20:24 < mmcgrath> setting things up initially won't take long
20:25 < mmcgrath> it's getting them working and coming up with a solid maintanence plan that will be the tricky part.
20:25 < dgilmore> mmcgrath: what base are we using?
20:25 < mmcgrath> dgilmore: RHEL
20:25 < mmcgrath> and xen at first
20:25 < dgilmore> mmcgrath: ok
20:25 < mmcgrath> though the conversion to kvm should be quick
20:26 < dgilmore> did we sort out the libvirt-qpid memory leaks?
20:26 < mmcgrath> dgilmore: nope, I've got a ticket submitted upstream
20:26 < dgilmore> mmcgrath: any reason not to start with kvm?
20:26  * mmcgrath is hoping to find some C coders to submit patches for me.
20:26 < mmcgrath> dgilmore: not really
20:26  * dgilmore set up new box in colo with centos 5.4 and kvm 
20:26 < dgilmore> its working great
20:27 < jokajak> i use kvm with my rhel 5.4 box and it works much better than xen ever did
20:27 < mmcgrath> the memory leak *might* be limited only to libvirt-qpid installs that can't contact the broker.
20:27 < mmcgrath> jokajak: that's weird, we've had generally the opposite experience.  Performance has either been terrible or as good as xen but never better.
20:27 < dgilmore> i never got the deps sorted out to get libvirt-qpid  running on my new box
20:27 < jokajak> i had stability problems with xen
20:28 < Oxf13> mmcgrath: I think it depends on what you install into the vm, and whether or not virtio is used
20:28 < mmcgrath> dgilmore: yeah, I need to come up with a long term plan for that too.
20:28 < Oxf13> without virtio, kvm is going to be slower than paravirt xen
20:28 < mmcgrath> Oxf13: yeah for us most issues were cleard with different drivers
20:28 < mmcgrath> I think we have most of it figured out now, our app7 is kvm
20:28 < nirik> kvm works great  here, but I am using fedora hosts. ;)
20:28 < mmcgrath> nirik: yeah
20:28 < mmcgrath> so anyone have any questions on this for now?
20:29 < dgilmore> the most recent rhel kernel fixed some clock issues i was having
20:29 < mmcgrath> k
20:29 < mmcgrath> #topic Hosted automation
20:29 -!- zodbot changed the topic of #fedora-meeting to: Hosted automation (Meeting topic: Infrastructure)
20:29 < mmcgrath> jaxjax: you want to talk about this?
20:29 < jaxjax> yep
20:29 -!- jpwdsm [~jason at desm-45-237.dsl.netins.net] has joined #fedora-meeting
20:30 < jaxjax> I'm currently in the process of installing a full environment on a kvm v machine
20:30 < jaxjax> testing on my desktop was a bit crap and I expect to have it ready by end of this week so I can test properly
20:31 < jaxjax> some questions about fas integration
20:31 < mmcgrath> <nod>
20:31 < mmcgrath> sure, whats up?
20:32 < jaxjax> Can I work in the automatic creation of groups when required?
20:32 < jaxjax> or we would have to do it manually?
20:32 < mmcgrath> jaxjax: yeah, and it'll be required almost every time.
20:32 < mmcgrath> ricky: you still around?
20:32 < ricky> Yup
20:32 < mmcgrath> ricky: would you be interested in writing a CLI based fas client that creates groups?
20:32 < ricky> I don't think we have write methods exposed in FAS yet, so that will require FAS extra
20:32 < ricky> **extra FAS support
20:33 < mmcgrath> once you're logged in couldn't you just post?
20:33 < ricky> Well...  I guess you can use the normal form and skip past having a JSON function for it
20:33 < ricky> You will probably just have hacky error handling in that case.
20:34 < jaxjax> Ricky: Do you mind if I contact you 2morrow or Sat for this?
20:34 < mmcgrath> ricky: well, should we focus on getting SA0.5 out the door so we can continue working on stuff like that?
20:34 < ricky> Yes
20:35 < ricky> jaxjax: Sure, eitiher of those is fine
20:35 < jaxjax> thx, will do.
20:35 < mmcgrath> k
20:35 < mmcgrath> we'll have to meet up and figure out exactly what is still busted
20:35 < ricky> There's currently a privacy branch in the git repo
20:36 < ricky> (privacy filtering is the current main broken thing)
20:36 -!- sijis [~sijis at fedora/sijis] has joined #fedora-meeting
20:36 < ricky> There's basically one design decision I'd like to make before we can refactor all privacy stuff :-)
20:37 < mmcgrath> ricky: is that something you can work on in the comming week?
20:37 < ricky> Yeah, I'll get started on that this weekend
20:37 < mmcgrath> ricky: excellent, happy to hear it
20:37 < mmcgrath> anyone have anything else on this topic?
20:38 < mmcgrath> k, we'll move on
20:38 < mmcgrath> jaxjax: thanks
20:38 < mmcgrath> #topic Patch Wed.
20:38 -!- zodbot changed the topic of #fedora-meeting to: Patch Wed. (Meeting topic: Infrastructure)
20:38 < mmcgrath> smooge: want to take this one?
20:38 < ricky> Haha
20:38  * sijis is here late. sorry
20:38 < smooge> yes
20:39 < smooge> Ok I would like to make every second Wednesday of the month patch day
20:39 -!- fbijlsma [~fbijlsma at p54B2C984.dip.t-dialin.net] has joined #fedora-meeting
20:39 < smooge> we would run yum update on the systems and reboot as needed
20:39 < smooge> which lately has been, we will be rebooting every 2nd wednesday of the month
20:40 < mmcgrath> smooge: do you want to alter when our yum nag mail gets sent to us?
20:40 < mmcgrath> right now I think it's on the first day of the month
20:40 < smooge> yes. I will change it to the first weekend of the month
20:40 < smooge> close enough for government work
20:40 < smooge> in the case of emergency security items, we will patch as needed
20:41 < mmcgrath> yeah
20:41  * mmcgrath is fine with that
20:41 < mmcgrath> anyone have any issues there?
20:41 < smooge> usually systems will need to be rebooted per xen/kvm server
20:41 < mmcgrath> smooge: It'd be good to get this in an SOP
20:41 < mmcgrath> now that we're getting some actual structure around it.
20:41 < smooge> yes
20:42 < smooge> I have two in mind
20:42 < smooge> update strategy, server layout strategy
20:42 < ricky> Just curious, is this roughly the way big companies, etc. do updates?
20:42 < smooge> making sure we have services on different boxes so we don't screw up things too much
20:42 < smooge> it depends
20:43 < smooge> some big companies will do them at something like 2am every saturday morning
20:43 < smooge> some big companies will do them once a month
20:43 < smooge> and some will rely on their sub-parts to do it appropriately (eg never)
20:43 < ricky> But nothing like "reboot the db server automatically once a month," right?
20:43 < jaxjax> nop
20:43 < smooge> depends on the db server
20:43 < smooge> if it has a memory leak then yes
20:44 < mmcgrath> heh
20:44 < jaxjax> you dont do the updates for all servers at the same time
20:44 < ricky> Hahaa
20:44 < jokajak> why not use something like spacewalk to better manage updates?
20:44 < mmcgrath> jaxjax: because then we'd be using spacewalk?
20:44 < mmcgrath> doesn't that still require oracle anyway?
20:44 < smooge> we might when its postgres support is ready
20:44 < wzzrd> yes it does
20:44 -!- JSchmitt [~s4504kr at fedora/JSchmitt] has quit Remote host closed the connection
20:45 < smooge> jokajak, it is a good idea. we are just having to wait for things we have little knowledge of to help with
20:45 < mmcgrath> smooge: got anything else on that?
20:45 < skvidal> how does spacewalk help?
20:45 < smooge> jaxjax, yeah you usually schedule the servers into classes and do them per 'class' so that services stay up
20:45 < jaxjax> sorry was at phone
20:46 < smooge> skvidal, knowledge of what boxes are in what state.
20:46 < mmcgrath> skvidal: it makes it easy to track what servers need updates, send the 'do the update' requirement and see how it went afterward.
20:46 < skvidal> smooge: and massive infrastructure to do that
20:46 < jaxjax> yes normally what you wanna is avoiding downtime because some patches make the system not working properly
20:46 < ricky> Is it necessary to reboot the xen machines as often as the other ones?
20:46 < mmcgrath> I have to say that aspect of satellite did appeal
20:46 < mmcgrath> skvidal: yeah it does have a cost
20:46 < skvidal> mmcgrath: a huge cost
20:46 < mmcgrath> ricky: they keep releasing kernel updates.
20:46 < ricky> They don't seem to touch sa much user data, so it's nice to avoid rebooting them if we can :-)
20:46 < smooge> I wouldn't call it  a huge cost
20:46 < skvidal> mmcgrath: and for more or less 'yum list updates' that's a lot of crap to sift
20:47 < smooge> its pretty minimal compared to some of the beasts I have had to deal with
20:47 < ricky> Ah, I was thinking about the value of security updates on those vs. on proxies, etc.
20:47 < skvidal> smooge: you have to run an entire infrastructure and communiucations mechanism
20:47  * nirik notes some of the kernel updates lately don't pertain to all machines. 
20:47 < mmcgrath> skvidal: updating all of our hosts monthly has become expensive though too.
20:47 < nirik> ie, driver fixes where the machine doesn't use that driver at all.
20:47 < skvidal> mmcgrath: how would spacewalk help that, then?
20:47 < mmcgrath> it's just a couple of clicks and it'll go do the rest.
20:47 < skvidal> mmcgrath: I'm not arguing against patch wednesday
20:47 < skvidal> I'm arguing against spacewalk being the answer
20:48 < mmcgrath> yeah I'm not so sold on spacewalk either
20:48 < mmcgrath> but the way we do updates now is pretty expensive.
20:48 < smooge> skvidal, I didn't say it was the answer. I said it "might" be the answer
20:48 < skvidal> smooge: let's talk about other solutions
20:48 < smooge> when the time comes it will be evaluated against what other frankenstein we can come up with to do it better
20:48 < mmcgrath> skvidal: FWIW, no one's actually said "we should use spacewalk"
20:49 < mmcgrath> jaxjax just asked why we don't and we told him :)
20:49 < smooge> I am not against frankensteins.. Its the Unix way
20:49 < skvidal> smooge: I'm not talking about frankensteins, either
20:49 < smooge> oh I am.
20:49 < jaxjax> I see.
20:49 < jokajak> s/jaxjax/jokajak ;-)
20:49 < skvidal> I'm talking about using the tools we have
20:49 < mmcgrath> oh jokajak
20:49 < mmcgrath> jokajak: jaxjax: wait, you two aren't the same person?
20:49  * mmcgrath only just realized that
20:49 < skvidal> smooge: do you have a rough set of requirments?
20:49 < mmcgrath> I kept thinking jaxjax was changing his nic to jokajak :)
20:49 < jaxjax> :D
20:50 < jaxjax> not at all
20:50 < smooge> skvidal, yes.. and when you assemble them together they become a frankenstein of parts. talk off channel after meeting
20:50 < skvidal> smooge: ok
20:50 < mmcgrath> Ok, anyone have anything else on that?  if not we'll open the floor
20:51 < mmcgrath> alrighty
20:51 < mmcgrath> #topic Open Floor
20:51 -!- zodbot changed the topic of #fedora-meeting to: Open Floor (Meeting topic: Infrastructure)
20:51 < mmcgrath> anyone have anything else they'd like to discuss?
20:51 < mmcgrath> any new people around that want to say hello?
20:51 < jpwdsm> I think OpenID might (finally) be ready for some testing
20:51 < sheid> hello, i'm new ;)
20:51 < mmcgrath> jpwdsm: oh that's excellent news.
20:52 < mmcgrath> jpwdsm: how far away from it being packaged and whatnot
20:52 < jpwdsm> I can log into StackOverflow and LiveJournal with it, but that's all I've done
20:52 < mmcgrath> jpwdsm: is it directly tied to FAS or is it it's own product?
20:52 < mmcgrath> jpwdsm: test opensource.com
20:52 < jpwdsm> mmcgrath: own product
20:52 < ricky> Nice :-)  What publictest are you on again?
20:52 < jpwdsm> mmcgrath: will do
20:52 < jpwdsm> ricky: pt6.fp.o/id
20:52 < ricky> For what it's worth, I haven't had luck with opensource.com and google or livejournal's openid :-(
20:52 < mmcgrath> sheid: welcome
20:53 < ricky> Good to hear - I look forward to dropping openid out of FAS :-)
20:53 < jpwdsm> mmcgrath: I haven't done much packaging, so I'll probably need some help with that
20:53 < jpwdsm> ricky: It uses FasProxyClient, but that's it :)
20:53 < ricky> abadger1999 is our python/packaging guru, and we're all around if you have any questions on it
20:54 < ricky> We'll also want to ask abadger1999 and lmacken about using the FAS identity provider (and if the TG2 one works with pylons)
20:54 < mmcgrath> <nod>
20:55 < ricky> (disclaimer if you're not aware - this is written in pylons, which is kind of a subset of TG2 I guess)
20:55 < mmcgrath> yeah
20:55 < mmcgrath> Ok, anyone have anything else they'd like to discuss?  If not we can close the meeting.
20:56 < Oxf13> I'd like to point out something for no frozen rawhide
20:56 < dgilmore> Oxf13: have at it
20:56 < G> oh, Infra meeting?
20:56 < Oxf13> my initial tests of doing two composes on two machines at once was favorable.  there was not a significant increase in the amount of time necessary to compose
20:56 < mmcgrath> Oxf13: sure
20:57 < mmcgrath> G: hey
20:57 < G> damn, I was awake for it too
20:57 < mmcgrath> heheh
20:57 < dgilmore> Oxf13: :)  nice
20:57 < Oxf13> this combined with lmacken's testing of bodhi means I think we can move forward with no frozen rawhide
20:57 < ricky> Have koji01.stg and releng01.stg been good for you and lmacken's testing?
20:57 < Oxf13> which means we will be stressing things more in the near future
20:57 < Oxf13> and ti's going to cause a lot of confusion amongst the masses
20:57 < ricky> (and cvs01.stg)
20:57 < mmcgrath> Oxf13: that should be fine and we should have more hardware for you
20:57 < G> The good news guys, when I'm back in NZ  I'll be able to attend them more often
20:58 < Oxf13> ricky: it was for luke.  I wasn't using .stg for my testing
20:58 < mmcgrath> G: excellent :)
20:59 < Oxf13> ricky: I will be using .stg for dist-git testing soon, but that will require modifications to koji.stg
20:59 < mmcgrath> Oxf13: Ok, well I'm glad that's working out for you
20:59 < ricky> Cool
20:59 -!- Ac-town [~dymockd at shell.onid.oregonstate.edu] has quit Changing host
20:59 -!- Ac-town [~dymockd at fedora/Actown] has joined #fedora-meeting
21:00 < mmcgrath> ok, if that's it I'll close the meeting
21:00 < mmcgrath> #endmeeting
21:00 -!- zodbot changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Meeting_channel for meeting schedule
21:00 < zodbot> Meeting ended Thu Feb  4 21:02:02 2010 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot .
21:00 < zodbot> Minutes:        http://meetbot.fedoraproject.org/fedora-meeting/2010-02-04/fedora-meeting.2010-02-04-20.01.html
21:00 < zodbot> Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2010-02-04/fedora-meeting.2010-02-04-20.01.txt
21:00 < zodbot> Log:            http://meetbot.fedoraproject.org/fedora-meeting/2010-02-04/fedora-meeting.2010-02-04-20.01.log.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20100204/a0255c44/attachment.bin