20:01:53 #startmeeting Fedora Infrastructure 20:01:57 * ricky 20:02:04 hey. 20:02:06 * thekad just is 20:02:06 #topic rollcall 20:02:07 no. 20:02:14 * onekopaka 20:02:16 * LinuxCode  20:02:19 hi guys 20:02:21 * ricky (again) 20:02:29 sorry.. I got / and # mixed up 20:02:36 stickster: are you going to join us? 20:02:39 so I was trying to figure out why /startmeeting wasn't doing anything 20:02:43 * iarlyy ( learner ) 20:02:57 here 20:03:17 hello everyone and thankyou for arriving before I did :) 20:03:38 * nirik is here in the back 20:03:45 Anything for you smooge ;-) 20:04:23 * sijis is here. 20:04:24 smooge: the bill is in the mail 20:04:38 abadger1999: quit being nice to smooge. He'll get used to it and expect things to be that way 20:04:40 .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 20:05:05 #topic Important Tickets http://tinyurl.com/2hyyz6 20:05:06 #link http://tinyurl.com/2hyyz6 20:05:10 skvidal: Sorry. I'll call him out for a duel later. 20:05:42 We currently have one one important one and one that I will have in an hour or so 20:05:49 that the AGPL issue ? 20:05:57 abadger1999, the important ticket is the one for you 20:06:10 no, nvm 20:06:15 abadger1999: you don't have to go quite that far - some casual passive-aggressive abuse is all that's really necessary :) 20:06:29 #topic tickets 1503 20:06:41 I've updated the implementation proposal: 20:06:43 https://fedoraproject.org/wiki/Infrastructure_Licensing#Implementation 20:07:03 It now has a rough plan for dealing with staging and publictest envs. 20:07:12 ricky: Does that look doable to you? 20:07:41 It's basically mod_auth_pgsql on the proxies for staging; mod_auth_pam individually for each publictest. 20:07:55 * ricky is reading though it now 20:08:39 I'm not crazy about mod_auth_pam 20:08:57 publictest servers are generally designed to be public so that everybody can see the progress 20:09:11 For example, with the docs team and zikula - most interested people aren't in sysadmin-test 20:09:34 20:09:50 ricky: for that matter, staging is designed to be open for people to test. 20:10:05 The thing is... we have to have some limit if we deal in AGPL. 20:10:11 If this will be a burden we will have for *only* AGPLv3 apps, then it's their loss for whoever is testing the AGPL code 20:10:22 maybe limiting to cla_done ? 20:10:28 But it would be really bad if this had to affect everything on those machines. 20:10:55 wait a tic 20:10:57 It will have to affect everyone on staging. 20:11:01 thekad, that would allow everyone access 20:11:03 * f13 just had a wonderful idea. 20:11:04 well actually... 20:11:17 LinuxCode, everyone in fp.o 20:11:22 does the AGPL allow for you to just put in a link that says "please contact if you would like a copy of the source" ? 20:11:22 No I think we could do per-machine in publictest and per-app in staging. 20:11:28 thekad, exactly, that is not desirable 20:11:28 f13: No. 20:11:31 and if so, we could just use that, and... 20:11:32 damn. 20:11:46 f13, from what I gathered no 20:11:51 * abadger1999 finds the license to be sure he's correct on that. 20:11:54 ok, crawling back into my hole. 20:11:56 It has be out there, i.e. a link 20:11:58 If anything, I'd rather do the "always keep the copy of source in staging/testing publicly avaliable" thing for only AGPL apps than go with the annoying password stuff 20:12:12 ricky, what if we added a new layer? privatetest servers? 20:12:21 f13: I was told that that was one of hte differences between GPL and AGPL. 20:12:58 I'd rather not keep the source... especially in publictest. 20:13:17 My goal is to keep the burden of AGPL compliance on the author of the apps completely. 20:13:17 abadger1999, and that is where the infra people collided with legal 20:13:35 And not inconvenience their testers, other people on the machines, etc. 20:13:37 Because publictest is essentially a development box that may have more resources or a public IP compared to someone's personal machine 20:13:38 ricky, yes, but then we get the patch issue 20:13:43 the only other item we could ask for is an worded exception from Legal for our apps where if they are on XYZ system we do not have to share the bits because they are not 'stable' 20:13:48 patches we use, have to be out there too 20:14:03 smooge, hmmm 20:14:07 Yes, and the people that chose that license should deal with it. 20:14:12 I dont think that will go down too well 20:14:19 smooge, spot would have to ask 20:14:32 If they're doing a test deploy straight out of a git repo, that could be fine for them 20:14:41 ricky: Are they liable or are we? 20:14:46 ricky, if the code is accessible, yes 20:14:56 But I'd rather keep the burden off of testers/users/other people that didn't choose AGPL :-) 20:15:13 if we patch, and dont make that patch public, we are the non-compliant party 20:15:28 ricky: So... is we have two diffrent types of publictest we can have one steup for AGPL apps and one setup for nonAGPL. 20:15:35 ricky: in puppet. 20:16:02 As much as I hate the idea of us bending over backwards for just the AGPL apps, sure, that could work 20:16:08 question is... what about a proposed patched that is being tested? does that need to be public? 20:16:22 sijis, technically from what I gathered, yes 20:16:26 That seems like something that isn't all that painful from the "everybody else" standpoint, at least. 20:16:34 Unfortunately the same doesn't really apply to staging 20:16:49 ricky: And in staging we could put do per in the config. 20:16:49 abadger1999, to go over who is liable in such cases it is usually covered via an SLA or OLA where we say we host items for a "group" and that group has to maintain licenses etc.. if we find they are not we have the right to remove such code/etc. 20:16:53 Staging tends to be deployed using RPMs though for what that's worth 20:17:12 sijis: yes. 20:17:13 But if anything, this still impacts the non-sysadmin-test people who are testing the app 20:17:22 And I'd really hate to burden testers more. 20:17:34 (With having to apply/request an account) 20:18:00 hey its fedora.. if you don't sign the CLA do we care about you :P 20:18:08 ricky, the problem is also that they will have to send the code to two places 20:18:18 So we can proceed two ways from here -- A) Come up with something better. B) decide we aren't going to relicense to AGPL (And pressure fedora community to move away from it) 20:18:25 one for hosting, to comply with availability requirements, second is for testing itself 20:18:35 or just not let fedora community onto staging/publictest I suppose. 20:18:38 My suggestion for A) is basically nirik's comment about gnuherds.org 20:18:46 production we have a good plan for, I think 20:18:48 Make the footer configurable, keep a tarball on ahnd 20:18:49 **hand 20:19:07 And retar/copy to a special directory on the publictest that's linked from the footer every time you make a change 20:19:22 It might be something you do every time you restart apache to reload the changes 20:19:38 abadger1999, I believe many people are adamont about agpl use, as they want to require other user, of for instance Fedora community, to make their code available 20:20:07 Do that for the AGPL apps in staging/production (which are hopefully setup in a way so that the configuration is in a separate location) 20:20:12 so it doesnt end up being a one-sided development 20:20:17 LinuxCode: that's fine... but it may mean we just can't offer the same support for developing Fedora Community than other apps. 20:20:32 abadger1999, I see both arguments here 20:20:41 it is not me who you have to convince hehe 20:20:55 So that way, the AGPL people get their AGPL, and they're responsible for keeping compliance (which doesn't seem all that painful for them to maintain on a single publictest/staging machine) 20:21:02 ricky, wasnt the config going to be under a different license 20:21:03 ? 20:21:08 I thought that was agreed 20:21:17 Instead of us having to lock people out of public things 20:21:23 ricky: So... I think we're going to run into some problems with that. 20:21:56 ricky: But I'd need to look at the AGPL again.... in GPLv2 there were things like "Prefered form of modification" 20:22:01 when defining source. 20:22:24 What kinds of problems would we run into? 20:22:24 I don't think that tarball of currently running code necessarily fits that. 20:22:47 Ah. We'll need to find out exactly what that phrase means then. 20:23:03 Do you happen to be familiar with what some of the requirements for that are? 20:23:07 The script would also need to either be pretty generic or pretty specific -- as it would have to get every piece of source needed to run the service. 20:23:19 which would be spread out to different parts of the filesystem. 20:23:23 Like nirik mentioned, that's what gnuherds.org apparently does :-) 20:23:40 * nirik nods. 20:23:43 ricky: gotta look up what AGPLv3 says... I'm only familiar with some of the arguments surrounding GPLv2. 20:23:50 ricky, just to clarify, if a test system is available online, but meant not for public use, you are still liable to the AGPL requirements. 20:24:00 * abadger1999 notes 20 minutes. 20:24:04 Yes, just because it's available 20:24:31 grepping for preferred, the only thing I see is: 20:24:32 The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. 20:24:45 there was still discussion on that point though 20:25:39 ricky: yeah - so the wording is in there. We'd have to run it by legal to tell us what "preferred form of the work for making modifications" allows us to do. 20:26:27 ricky: (heh... and it will fail if someone writes some java code or uses google web toolkit to generate javascript) :-( 20:26:47 Well, they wouldn't be live patching the generated javascript in staging, would they? 20:26:52 or C python modules for speedups. 20:27:36 we use stawging in different manners which is part of hte problem. 20:27:37 How about: Is SCM + tag + directory containing changed files sufficient? 20:27:42 ok I would like to close this up in 5. 20:27:55 agpl is a bitch 20:27:56 this being this topic 20:27:58 lol 20:28:20 Anyway, my main point is that I want to put the burden on the developers, not the other users of the machine or the people testing the app. Especially since we only have one AGPL app at the moment. 20:28:28 So yeah, I can see live patching generated javascript in staging if I wanted to test whether a simple change would fix something. 20:28:47 ricky: The proposal is to relicense all of our web apps. 20:29:11 ricky, yeh makes sense 20:29:13 * ricky isn't crazy about the idea given the above list of painful things :-) 20:29:40 ricky, tbh I dont even think the AGPL affects "normal users" 20:29:41 ricky: Right. So we have two action items: 1) How can we make this less painful. 20:30:11 2) Based on answers to 1), decide if we should do it? 20:30:13 somebody will have to run this by legal and ask if it is possible to make a disclaimer, making the devs liable 20:30:15 2) If we can't make this less painful, we'll have to decide at some point if the pain is worth it or if we should choose a different license. 20:30:31 and if the agpl would accept that disclaimer 20:30:32 ricky: Yep. Like GPLv2+ for instance. 20:31:14 abadger1999, if the javascript is LGPL2+ and the app is AGPL. Do we share the patches for the LGPL2+ stuff immediately? 20:31:23 OK, that's all I have to say on that pending answers/suggestions to the "how can we distribute the source on staging/publictest without locking them down" question 20:31:37 smooge: According to spot, things the app uses are not subject to the AGPL. 20:31:42 smooge: Only the app itself. 20:31:56 even the configs arent part of Section 13 of the AGPL 20:31:59 so I would say that if its going to be up to the developer to deal with it 20:32:00 smooge: I'm not clear on how it would affect a library that was licensed under the AGPL. 20:32:10 It gets even more painful when we have to deal with 3rd party AGPL apps 20:32:30 3rd party apps that may not make the footer configurable or give us an easy way to make local patches 20:32:44 and we would want to make our stuff set up as LGPL2+ where its going to be included ins something else 20:32:46 ricky, good point 20:33:17 ricky: yep -- we'd immediately have to patch teh third party app to link to the source we use and put the patch into a hotfix ticket/the rpm. 20:33:18 As we've seen here, there are ways to make things incredibly painful :-) 20:33:36 hehe 20:33:53 Like if the patch to the footer is a patch to a generated file. 20:34:08 smooge: -- In the Infra Licensing Guide, I say we're going to default to using LGPLv2+ for libraries, python modules, etc. 20:34:08 the AGPL is generally a good idea in terms of freedom of software and dev of that software 20:34:14 A simple (or even critical security fix for example) could become a nightmare to do properly. 20:34:18 but for people running or deving its a bit of a pain 20:34:36 ricky: And then we might say, we are not going to run this app unless upstream applies the fix. 20:34:42 ricky: yes and no 20:34:56 And we've had to do those kinds of changes with FAS before. 20:34:58 ricky: you just need to make the source available when you deploy the fix 20:35:01 ok how much longer do people want to go over this? 20:35:01 ricky, the patch issue, could be deemed configuration, maybe something to ask legal for advice about... 20:35:01 Err... fix == allow the footer to be configurable. 20:35:08 smooge: lets move on 20:35:15 smooge: I'm ready to move on. 20:35:28 dgilmore: abadger1999 brought up some example with generated javascript, for example, where that becomes a mess 20:35:32 * ricky is ready to move on as well 20:35:44 +1 20:35:51 #topic #1588 20:35:54 could discuss this a whole week 20:36:34 Ok next thursday we will be doing a reboot of a lot of the infrastructure systems 20:37:04 most of the boxes have not rebooted or rebooted to the correct kernel for 2+ errata so its time to get er done 20:38:34 do people have any comments on this? Buildsystem is the only one that I do not think will be affected 20:38:49 about time... 20:38:50 smooge: Do you need help? 20:38:52 ;-p 20:39:28 yes 20:39:35 abadger1999, yes I do 20:39:38 that is 20:39:42 We'll need to make sure grub.conf is pointing at the right kernel first 20:39:53 That may have been something we've overlooked before. 20:39:58 Okay. 20:40:09 I noticed that on a bunch of machines, it was not pointing to the newest kernel installed for some reason 20:40:44 ricky: might have been a reason for it 20:40:53 smooge, have we ever tried to deploy infra using live kernel patching ? 20:40:53 Then we'll want to find out what that was :-) 20:41:06 * abadger1999 fills in calendar: Thurs is for junior assistant sys admin work :-) 20:41:20 xen15 is an example of one 20:41:21 LinuxCode, no. If RHEL does not ship it we dont use it in production (for the most part) 20:41:28 smooge, makes sense 20:41:29 Er, xen13 20:42:00 I would like to have all bugs found where we need to stay with an older kernel to be filed. 20:42:21 where is the best place for that? trac wiki? trac tickets? email? 20:43:16 smooge, if that's gonna change in the future, tickets, if not, wiki 20:43:29 trac ticket with a keyword. 20:44:00 ok cool. 20:44:09 keyword: Omega Armageddon 20:44:17 lol 20:44:32 :-) 20:44:33 who says it will be the last armageddon ? hehe 20:44:36 ;-p 20:44:49 We roll over to Alpha Alpha Armageddon 20:44:53 haha 20:44:55 k 20:45:01 Armageddon-rc1 ? 20:45:11 are there any known gotchas from the last one? 20:45:18 last ones? 20:45:33 * ricky can't think of any reason to not boot the latest one apart from testing for a bug or something 20:45:51 ok cool 20:46:01 2.6.18-128.2.1.el5 ? 20:46:07 * LinuxCode cant think of anything 20:46:48 yes we should be on that one.. unless in the next week we have 2.2 or 3.0 or something 20:46:51 ricky: Was the xen server that keeps rebooting thing resolved? 20:47:01 I know we tried a specific kernel for that at one pint. 20:47:04 Nope although it hasn't happened as of late 20:47:04 **point 20:47:16 That was xen13, which is fixed on an older kernel now (maybe for that reason?) 20:47:26 Yeah, that's what I'm wondering. 20:47:31 Sorry, fixed as in on that particular kernel, not the problem :-) 20:47:37 20:47:51 The last I heard of that was it being fixed in rhel5u4 though 20:47:52 ricky, might be worth to give the new one a whirl 20:47:58 ohh ok 20:48:04 So not something we're using yet. 20:48:39 hey lets run the beta 20:48:54 * LinuxCode hits smooge 20:48:58 lol 20:49:04 smooge: Might be good to send that outage to devel-announce too 20:49:09 * LinuxCode recalls a security issue with the beta 20:49:16 ah good idea 20:49:19 thanks ricky 20:49:29 We should actually be able to do it without mirror list ouages 20:49:32 Or DNS 20:49:45 Or mail 20:49:53 If we do it intelligently :-) 20:50:04 For everything else, there'd be a blip when the dbs/CVS went down 20:50:15 ricky, you realize that right now you have doomed us all, right? 20:50:28 Hehe 20:50:30 smooge, please send an email to the infra list too please 20:50:39 He just sent one :-) 20:50:41 LinuxCode, I thought I just did 20:50:43 ohh lol 20:50:45 sorry 20:50:53 ok I think we are to the next topic 20:50:58 I was still filtering for agpl sorry 20:50:58 #topic Open Floor 20:51:14 Any new people want to say hi now? :-) 20:51:43 I saw a couple earlier on 20:51:54 iarlyy, hi 20:51:59 Also one more thing on the outage 20:52:13 buildsys might be affected momentarily if xen2/nfs1 are on the list 20:52:53 ricky, might be smart to figure out a procedure for reboots 20:52:54 So yeah, there'll be a bunch of people to ping in advance 20:52:57 and write it down 20:52:59 Yeah, this needs to be SOPized 20:53:06 This will be a good chance to do that 20:53:23 * ricky is making a list of machines with SPOFs on them now 20:53:27 yeah.. my first SOP 20:53:31 or my second.. 20:55:29 ok so buildsys will be affected I will ammend 20:56:39 anything else ? 20:56:45 * LinuxCode needs to jet to the shop 20:57:22 Enter into the record that mmcgrath has a firstborn ;-) 20:57:40 wow 20:57:53 oh yes. 20:58:04 congrats to mmcgrath! 20:58:14 abadger1999: with the initials of 'rpm' 20:58:16 #record mmcgrath has a new born kid and will be on short shift for a while 20:58:43 smooge, for the next 18 years I believe :P 20:58:46 smooge: it's @infoo. 20:58:50 #info* 20:59:03 #info mmcgrath has a new born kid and will be on short shift for a while 21:00:02 I thought they were trying for one 21:00:05 lol 21:00:11 that was quick! 21:00:18 * LinuxCode must have misunderstood 21:00:18 skvidal, and we noticed your patch request for the next child to be Yolanda Ulysses Mcgrath 21:00:28 Yolanda Ursula 21:00:38 skvidal, Ursula! 21:00:39 lol 21:00:43 PLEASE NO 21:00:46 lol 21:00:56 no one gets my jokes 21:01:01 skvidal, lol 21:01:25 If its a boy it will be Yojimbo Ulysses? 21:02:51 skvidal, I got the joke.. I just forgot the Ursula unless there was a deeper joke with Ursula LeGuin I missed 21:04:02 so we need to annouce on f-i-l that mmcgrath has a child now? 21:04:08 no 21:04:36 we should have a whole subsite newborn.fp.o 21:04:43 smooge: still say that if ajax ever has a kid, he has to name him lucious. 21:05:02 pjones, ok, I didn't get that one 21:05:14 I figured it would be shoeless 21:05:19 (http://en.wikipedia.org/wiki/Luscious_Jackson) 21:05:23 * ricky just googled for it 21:05:33 ricky: wrong. 21:05:41 Oh, the baseball player one? 21:05:50 Er, basketball :-) 21:05:52 http://en.wikipedia.org/wiki/Cool_Hand_Luke 21:05:58 that has nothing to do with ajax I think 21:06:04 Haha, wow 21:06:12 (what we have here is a failure to communicate.) 21:06:42 Heh 21:07:18 wait, this meeting is over now, right? 21:07:22 ok I think we are done now 21:07:23 thekad: nah. 21:07:27 #endmeeting