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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has joined #fedora-meeting 19:59 -!- JSchmitt [~s4504kr@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] has quit Changing host 19:59 -!- JSchmitt [~s4504kr@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@xxxxxxxxxxxxxxxxx] 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@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@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@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxxxxxxx] 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@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@xxxxxxxxxxxxxxxxxxxxxxxxxx] 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@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@xxxxxxxxxxxxxxxxxxxxxxxxxx] has quit Changing host 20:59 -!- Ac-town [~dymockd@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
Attachment:
pgpwvYUwDSRC7.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
