19:00:01 #startmeeting Infrastructure (2011-05-19) 19:00:01 Meeting started Thu May 19 19:00:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:01 #meetingname infrastructure 19:00:01 The meeting name has been set to 'infrastructure' 19:00:01 #topic Robot Roll Call 19:00:01 #chair goozbach smooge skvidal codeblock ricky nirik abadger1999 19:00:01 Current chairs: abadger1999 codeblock goozbach nirik ricky skvidal smooge 19:00:05 ooh... 19:00:09 rbergeron: did we do it again? 19:00:20 Oh. We did. 19:00:22 readyness and infra at the same time? ;( 19:00:24 I did. 19:00:32 Fail. 19:00:52 you want to do readyness in meeting-1? or should we move there? 19:00:53 oh noes! 19:01:01 * abadger1999 here 19:01:03 who had first dibs? :) 19:01:07 I can move. 19:01:10 Darnit. 19:01:13 and figures out where we're going :-) 19:01:16 rbergeron: we're sorry 19:01:17 * rbergeron makes a note on the time confusion. 19:01:18 rbergeron: :P 19:01:22 * rbergeron will head to #fedora-meeting-1 19:01:28 really really really sorry 19:01:48 sorry about that. I should have noticed too. ;( 19:01:51 shrug, we still here? 19:01:53 rbergeron: are we moving another channel? 19:02:08 noriko: yeah, #fedora-meeting-1 19:02:12 sorry 19:02:17 we are still here. They are taking #fedora-meeting-1 19:02:22 rbergeron: sorry. 19:02:23 nirik: kk 19:02:28 rbergeron: sorry 19:02:49 present! 19:02:55 * StylusEater_work is here 19:03:04 * janfrode is here too :-) 19:03:23 janfrode!!!! 19:04:01 cool. 19:04:12 Fedora Readiness meeting moved to #fedora-meeting-1 19:04:15 so, I guess lets get started... lets start with new folks intros... 19:04:40 Announcement from my owner (jsmith): Fedora Readiness Meeting now in #fedora-meeting-1 19:05:05 #topic New folks 19:05:13 Meeting Agenda Item: Introduction Jason Shive 19:05:33 Meeting Agenda Item: Introduction Jan-Frode Myklebust 19:05:51 Warren Thomas 19:05:55 any of you 3 here? 19:06:00 <--- Jason 19:06:01 I'm a sysadmin at an ISP doing using much the same software/tools as you fedora infrastructure guys.. Running RHEL5/6, puppet, kickstarts, bind, KVM, RHEV, etc.. 19:06:06 or any other new folks who would like to say hi? :) 19:06:20 janfrode: welcome! 19:06:27 Wanting to broaden horizon by joining the infrastructure group here :-) 19:06:30 welcome to jason and jan-frode 19:06:32 hello 19:06:34 Welcome to you both. 19:06:35 Klainn: welcome! 19:06:47 wileyman is here 19:06:47 Yo yo 19:07:01 I'm new here, used to almost all sysadmin tasks looking for interesting tickets to work 19:07:03 wileyman: <--- Jason Shive no? 19:07:10 Negative, I am 19:07:20 mosburn: welcome as well 19:07:25 I may be wiley, but that is not my nicknake. 19:07:25 so who wants to work on what? 19:07:33 So, I'd like to point to https://fedoraproject.org/wiki/Infrastructure/GettingStarted for everyone. 19:07:35 Warren Thomas <---- wileyman yes 19:07:49 Please do read that thru and hang out in #fedora-admin and/or #fedora-noc... 19:07:59 ask about tickets you are interested in or tasks you would like to help with. 19:08:32 I'm going to try and weed out some easyfix tickets I can point folks at to get started sometime in the next week or so. 19:08:57 but again, welcome and hopefully we will see more of you all in the coming weeks/months. ;) 19:09:15 I'm not too picky, if it's something I'm not familiar with I probably should be so hit me with whatever. 19:09:16 rbergeron: readiness meeting is coming here? 19:09:28 liknus: over in #fedora-meeting-1 19:09:34 oops thanks! 19:10:04 if any of you folks would like to be in the apprentice group so you can look around at our setup and decide what you might want to work on, see us in #fedora-admin after the meeting. 19:10:23 I've started a page on the apprentice group: https://fedoraproject.org/wiki/Infrastructure_Apprentice 19:10:35 please do edit, add, ask questions on it, etc. 19:10:57 ok, moving on to upcoming tasks: 19:11:02 #topic Upcoming tasks 19:11:18 REMINDER: we are in deep freeze for f15 release, which will be next tuesday. 19:11:29 so, avoid any changes to any systems without approval. 19:11:51 Other upcoming tasks: https://fedoraproject.org/wiki/Infrastructure_upcoming_tasks 19:12:14 I need to update the ical file, but that will have our upcoming stuff in an ical feed. 19:12:19 nice! 19:12:47 after freeze, I will publish that to a easy to remember set of urls. 19:13:23 Anyone have any other upcoming items they wish to schedule, see me. 19:13:33 Ideally we will be scheduling any outages a week in advance. 19:13:51 ? 19:14:04 StylusEater_work: go ahead 19:14:12 nirik: puppet changes need to be scheduled? 19:14:27 StylusEater_work: posted and then approved with 2 +1's 19:14:33 skvidal: roger 19:14:53 https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environments.png 19:15:11 if they affect any machine in the freeze zone, then yeah, must be approved. 19:15:42 ok, moving on to meeting tickets then... 19:15:48 #topic Meeting tickets 19:15:56 I'd like to go over the f15 final ones quickly. 19:16:03 https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=~Meeting&order=priority 19:16:24 * nirik waits for hosted 19:16:43 .ticket 2709 19:16:44 nirik: #2709 ([Fedora 15 Final] Communication with RH IS) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2709 19:16:59 I talked with them and they are aware to watch for any problems on release day or before. 19:17:17 .ticket 2711 19:17:18 nirik: #2711 ([Fedora 15 Final] Modify Template:FedoraVersion) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2711 19:17:23 thats on release day I think. 19:17:45 .ticket 2721 19:17:46 nirik: #2721 ([Fedora 15 Final] Mirror space) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2721 19:17:49 .ticket 2723 19:17:50 nirik: #2723 ([Fedora 15 Final] Permissions on mirrors) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2723 19:18:04 I think those are good, need to check to make sure. 19:18:20 .ticket 2720 19:18:21 nirik: #2720 ([Fedora 15 Final] New Website) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2720 19:18:37 I guess we don't have anyone from websites here? 19:19:00 nirik: they're discussing it in F-M-1 19:19:02 I can check with them. 19:19:03 :) 19:19:03 yeah. 19:19:47 ok, I think those are the release tickets that can be looked at right now. 19:19:47 sounds like elad661 says they're good to go 19:19:55 yeah. 19:20:10 anyone have any other release tickets we should address? or just meeting related tickets? 19:21:04 just meeting here 19:21:17 StylusEater_work: go ahead. 19:21:24 .ticket 2777 19:21:25 StylusEater_work: #2777 (/etc/system_identification missing on some hosts?) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2777 19:21:35 smooge: is ticket 2721 ok and safe to close? 19:21:54 one sec 19:21:57 with the help of smooge and skvidal I managed to document the puppet setup for /etc/system_identification 19:22:32 my question is we seem to be using servergroups (and the associated classes) for the file definition in puppet ... can I instead move this file definition to the host configs? 19:22:40 does that make sense? 19:23:15 or do we want to stick with servergroups and somehow generalize it or overwrite it per node? 19:23:30 cool. Thanks for working on it! 19:23:53 so, the question becomes are all machines in a servergroup the same security profile, or is that more a per host decision? 19:23:53 nirik, done 19:24:14 nirik: without verifying my suspicion is it varies 19:24:41 StylusEater_work, we have used servergroups because we may have 20 app servers and we are good at forgetting of updating 9 of them to the same level 19:24:53 how do we enforce security policiies one /etc/system_identification in place? 19:25:35 smooge: I understand and it makes sense but I believe we can make per node changes for things like node specific files. I'm willing to do it. 19:25:40 it's informational more than a enforcement item. 19:25:52 ie, it's to let you know when you login there what kind of machine you are dealing with. 19:26:04 smooge: I just wanted to get feedback before generating a large patch list for skvidal 19:26:09 StylusEater_work: I'd say propose your changes and we can look at the diff? 19:26:26 nirik: I suggested he attach it to the ticket on this 19:26:29 nirik: kk 19:26:41 hi there, late but here 19:26:46 sounds good. 19:26:46 skvidal: yes you did, but there are a lot of hosts to generate patches ... I know code talks but... 19:26:48 welcome CodeBlock 19:27:03 On tethered wifi on our way to dayton \o/, going 65 mph down a highway. <3 technology 19:27:04 StylusEater_work: yeah, sometimes it's a ton of small changes to many many files. ;( 19:27:12 CodeBlock: you're not driving, right? 19:27:26 skvidal: do you need to even ask that :| 19:27:30 No, I am not driving 19:27:34 good 19:27:37 does anyone have any other tickets they would like to discuss at this time? 19:27:46 StylusEater_work: again, thanks for looking at that 19:28:27 nirik: there was an item by codeblock 19:28:29 #topic Gather ideas for splitting hosted to more than one box 19:28:34 yep. it's next. ;) 19:28:35 thatstheone 19:28:38 * nirik was jumping around. 19:28:51 CodeBlock: care to discuss this one? 19:29:18 oh ..right 19:29:47 Yeah, so...as a summer project, I would like to discuss what needs to be done to split hosted off to several boxes, rather than just one (at serverbeach, no less) 19:30:00 Load on the primary hosted box is constantly 3-5ish 19:30:20 skvidal had some ideas on this a while back, but.. I'd like to revisit it 19:30:37 Will it work to have one editable host, and several readonly ? 19:31:03 skvidal: you here? 19:31:09 * skvidal is here 19:31:18 I think skvidal's original idea was to have some kind of central storage that each box would see and use for stuff 19:31:26 well it would be something like 19:31:29 that would be nice, but not easy to do. ;) 19:31:32 central, replicated storage 19:31:42 and then other boxes tying into that for accessing data 19:31:44 per-service 19:32:03 the services provided by hosted are: 19:32:11 $scm-access 19:32:20 $scm-ssh-commit-access 19:32:28 website 19:32:38 (trac) 19:32:41 (download) 19:32:57 mailman 19:33:19 that's it, right? 19:33:40 sounds right 19:33:45 if nothing else we casn break mailman out - trivially 19:33:50 s/casn/can/ 19:34:11 I think the big load is http... 19:34:18 search engines hitting the scm repos. 19:34:20 I think breaking out mailman would be good. 19:34:40 skvidal: what would you suggest for the storage? 19:34:54 http://fedoraproject.org/awstats/fedorahosted.org/ now has some web stats for us. 19:34:55 that's a great question :) 19:35:11 I had considered gluster/cloudfs but it is just not ready 19:35:17 it won't work for the way we need groups to work 19:35:20 * nirik has to step away for a sec. continue on 19:35:22 so that's a non-starter 19:36:07 So for the search engine stuff, .. after-freeze I'm wanting to get robots.txt in place. I tried twice at the start of the freeze, and nboth attempts failed/robots.txt still isn't working 19:36:09 sigh, this wifi is getting laggy 19:36:41 lustre might be something to investigate. 19:36:50 so where would we move mailman off to, first off? 19:36:52 or we could do something as simple as shared nfs 19:37:08 CodeBlock: anywhere, really - smtp is so easy to move around 19:37:22 's at nirik's evaluation of where load is coming from. web-repo viewers are a big part (and we have both trac and a standalone web viewer in many cases) 19:38:23 abadger1999: so that's the other weird issue 19:38:25 trac 19:38:27 I suspect mailman is almost none of the load. ;) 19:38:31 nirik: I do too 19:38:40 nirik: but it is also the easiest to move :) 19:38:54 Wouldn't also splitting off scm be easy, and free up file cache for the web viewers ? 19:39:15 janfrode: gotta have access to the data, 19:39:21 janfrode: and ssh-commit to that locaiton, too 19:39:31 well another thing splitting stuff off gives us is.. right now if hosted01 dies, we lose...mailing lists, trac, all repos. If we split it off, if one thing dies, ideally it won't break *everything* down 19:39:51 * nirik wishes they had pulled drbd into rhel6. ;( 19:39:53 s/break/bring/ 19:40:08 nirik: drbd really only gives us a copy 19:40:13 last time I looked it doesn't do two-way writes 19:40:35 it does in fact have a master/master mode. ;) (which you can put something like gfs2 on) 19:40:40 ah 19:40:42 I didn't know that 19:40:48 but gfs2 is kinda a pain. 19:40:54 * StylusEater_work has to leave 19:40:57 and it's not in anyhow, so don't mind me. 19:41:11 janfrode: so your suggestion 19:41:12 we could also split things by projects 19:41:18 break each scm out to a host? 19:41:29 nirik: by letter? 19:41:33 500 projects on hosted1, 500 projects on hosted2, alternate when adding new. 19:41:37 nirik: yes, but that kills the last thing I said ;) 19:41:38 janfrode: the issue of course is most of our projects are git 19:41:45 or some other critera that makes them about the same number. 19:41:49 CodeBlock: how? 19:42:15 nirik: I think the question I have is simple - how much can we spend on hosted? 19:42:16 No, I was thinking one host for scm/ssh, one for website/trac 19:42:30 nirik: what's our budget and how important is hosted to our mission 19:42:36 imo hosted seems pretty damned important 19:42:52 janfrode: yeah, but scm has to be mounted on website... and thats most of our load with spidering the scm content. ;( 19:42:54 * CodeBlock agrees, which is why I'd like to spend some of my summer giving it some love 19:43:05 so let's give the big example 19:43:13 skvidal: I agree. I think it's important and I'd like to see us enhance and make it awesome. 19:43:16 1 box for the mailing lists for collab and hosted 19:43:42 nirik: so proxy it in the web frontend ? 19:43:49 3 boxes for the trac/git/websites for the projects (hosted1/2/3 - divided up the project name) 19:44:09 1 box which has write access to all of the above 3 by nfs for commits? 19:44:28 so the 3boxes for the websites are essentially proxies 19:44:38 janfrode: yeah, we could potentially do some caching there... 19:44:42 hmm 19:44:42 which redirect you around internalyl to get to the right data directly from the host by http 19:45:22 it would be better than what we have, that's for sure 19:45:38 so if we were to lose one of those 3 boxes we'd only lose 1/3rd of the projects websites 19:45:47 yeah 19:45:59 and the mailing lists are immaterial here 19:46:17 so mailing lists would go on the same box as fpo lists? 19:46:44 * janfrode likes creating active/active/* cluster with IBM GPFS storage.. but that's proably not an option here..? 19:46:45 skvidal: and also could move those sites to one of the other ones. 19:47:02 but if the backend box died they would all die 19:47:15 nirik: I' msaying no backend 19:47:39 nirik: the 3 boxes host the actual data 19:47:39 oh I see... 19:47:49 and if we wanted to limit impact due to outage 19:47:57 each of those is at a different center, I'd think 19:48:41 yeah. 19:49:01 we could possibly cross replicate too if we wanted... rsync or something 19:49:01 and by doing the internal redirects from their apache servers 19:49:04 nirik: +1 19:49:17 hmmm 19:49:19 that would be nutty 19:49:26 do a raid config 19:49:30 so how would this work, budget wise? I realize I'm not the "right" person to ask that question, but .. could we afford something like that? 19:49:30 hosted1,2,3 19:49:39 each copies half of each of the others 19:49:49 oh no... not raid over NFS... please no 19:49:50 CodeBlock: it depends. ;) we would have to see where and what things we will have... 19:49:54 notactual raid 19:50:06 oh ok 19:50:07 rsync probibly would be good enough. ;) 19:50:15 smooge: I meant that if 2 hosts were up 19:50:23 we could reassemble all the data fro mthe other 2 19:50:35 CodeBlock: so instead of budget 19:50:40 let's look at a plan 19:50:43 and figure out cost 19:50:49 a couple of things which would help us, i think 19:50:52 * nirik thinks that sounds good. 19:50:57 1. how much space/mem we're using now 19:51:03 2. how many connections in any given month 19:51:04 yeah.. you will need to work out the locking mechanism and what happens when bob commits to X, joe commits to Y, and they haven't sunk up 19:51:08 3. growth rate of the above 19:51:12 so we can predict 19:51:19 smooge: there would not be any multiple writers 19:51:21 smooge: a single writer 19:51:24 just read-only replicated 19:51:36 no one is suggesting anything crazy - just keeping a hot copy 19:52:15 * nirik notes the awstats stuff is at least a start. We need to add in git.fh.o, etc after freeze. 19:52:27 nod 19:52:36 CodeBlock: so a suggestion 19:52:39 you want to work on this this summer? 19:52:54 that was my plan, yes 19:53:02 CodeBlock: how about you come up with a game plan by the week after next 19:53:22 that sounds good... 19:53:46 skvidal: sounds good - I'll throw something out on the list and get ideas too 19:54:31 the total disk space in use on hsoted1 is actually quite small 19:54:31 #action CodeBlock to gather more ideas and put together a longer term hosted plan by week after next. 19:54:39 yep. 19:54:48 ok, anything more on this? or shall we move on? 19:55:22 I had one more quick item before open floor I forgot I wanted to mention... 19:55:26 #topic Tickets 19:55:51 I'd like to try and get together for a few minutes sometime in the next few weeks with folks who have tickets assigned to them... 19:56:00 oh dear 19:56:12 so we can see whats done, whats easy, what can be nuked. 19:56:14 * skvidal goes to look 19:56:33 also, we have a bunch of tickets for things like pkgdb, fas, or websites that might be better on their own trackers. 19:56:52 skvidal: you only have 1 ticket I think. ;) 19:56:56 I just checked 19:56:58 I think I'm free! 19:57:08 https://fedorahosted.org/fedora-infrastructure/report/4 19:57:10 tickets by owner 19:57:21 Anyhow, if folks would like to corner me when they have time, or I can find them... it would be nice to get our trac down to sanity. 19:57:32 WRT the coding tickets -- we need to figure out how to make EasyFix easy to find. 19:57:55 Since putting them on fas, python-fedora, pkgdb, etc... makes it hard to find for people coming into infra. 19:58:02 abadger1999: yeah. I think keyword would be ok for that. 19:58:17 sure, but some of them would be best moved... but it will be on case by case basis. 19:58:23 But putting them all in fedora-infrastructure isn't logical with someone coming into it from the individual web apps. 19:58:40 Yeah. 19:58:47 well.. not sure about case-by-case. 19:59:15 it may work best that some are just pointers... 19:59:20 ie, see otherticket foo 19:59:25 If there's less places to search and a simple logic to figuring out where to search, I think that's much better than some easyfix here, some there. 19:59:33 that would work. 19:59:53 #topic Open Floor 20:00:01 ok, anything for open floor in the last few seconds? 20:00:04 too late. ;) 20:00:07 hah 20:00:37 * nirik will wait a few to see if anyone comes up with anything. 20:01:13 * CodeBlock just throws out a "good job" to everyone, with the freeze and such so far, etc. 20:01:23 encouragement++; 20:01:28 ;) 20:01:29 yeah, I am hoping for a nice smooth release. ;) 20:01:49 Thanks for coming everyone. :) Lets continue in #fedora-admin and #fedora-noc. 20:01:51 #endmeeting