From a.badger at gmail.com Tue Apr 1 01:00:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 31 Mar 2008 18:00:53 -0700 Subject: xen7 networking issue? In-Reply-To: References: <47F14C09.4030703@gmail.com> Message-ID: <47F18945.9020603@gmail.com> Mike McGrath wrote: > On Mon, 31 Mar 2008, Toshio Kuratomi wrote: > >> Someone just reported that the wiki was down and I thought xen7 might have >> crashed again. when I tried to ssh to it my connection timed out. ping xen7 >> was fine. I serial consoled in and then immediately tried to ssh to xen7 >> again. it worked. uptime showed that xen7 has been up since this morning and >> the app servers are all running, etc. There are no iscsi errors in >> /var/log/messages. >> >> Is there a possibility that we're experiencing some sort of networking issue >> with xen7? Maybe that issue is exacerbating the iscsi bug that causes our xen >> hosts to crash? >> > > you can ssh to (for example) fas1 then ssh to xen7. To clarify why this is, it's because fas1 is a xen guest on xen7. > I discovered that just > before I left on Friday. This leads me to believe that something else on > our network is using that IP. We'll have to look at the arp tables and > see whats going on. > heads up for the list: Mike found a mac address that's doing this: 00:1A:64:2C:81:02. > The good news is this shouldn't affect the xen guests though, in theory, > it is affecting the iscsi connection on xen7. xen1 and xen2 are the only > hosts we've seen actually rebooting though xen7 is new. > Clarification, xen7 has rebooted itself three times since you left :-/ And I've just had to reboot it because of this: Apr 1 00:32:53 xen7 kernel: scsi 2:0:0:0: rejecting I/O to dead device Apr 1 00:35:31 xen7 last message repeated 11 times -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From bugs.michael at gmx.net Tue Apr 1 12:04:26 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Apr 2008 14:04:26 +0200 Subject: FAS2 problems Message-ID: <20080401140426.951bf164.bugs.michael@gmx.net> 1) > Please submit bugs to https://fedorahosted.org/fas2/ gives just: Environment not found 2) https://admin.fedoraproject.org/accounts/dump-group.cgi 500 Internal Server Error From opensource at till.name Tue Apr 1 12:12:32 2008 From: opensource at till.name (Till Maas) Date: Tue, 01 Apr 2008 14:12:32 +0200 Subject: FAS2 problems In-Reply-To: <20080401140426.951bf164.bugs.michael@gmx.net> References: <20080401140426.951bf164.bugs.michael@gmx.net> Message-ID: <200804011412.37824.opensource@till.name> On Tue April 1 2008, Michael Schwendt wrote: > https://fedorahosted.org/fas2/ This seems to be changed to: https://fedorahosted.org/fas/ Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From linux at elfshadow.net Tue Apr 1 12:16:16 2008 From: linux at elfshadow.net (Jeffrey Tadlock) Date: Tue, 1 Apr 2008 08:16:16 -0400 Subject: FAS2 problems In-Reply-To: <20080401140426.951bf164.bugs.michael@gmx.net> References: <20080401140426.951bf164.bugs.michael@gmx.net> Message-ID: <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: > 2) > > https://admin.fedoraproject.org/accounts/dump-group.cgi This has been replaced with this I believe: https://admin.fedoraproject.org/accounts/group/dump/ ~Jeffrey From bugs.michael at gmx.net Tue Apr 1 16:51:17 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Apr 2008 18:51:17 +0200 Subject: FAS2 problems In-Reply-To: <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> Message-ID: <20080401185117.acf53be2.bugs.michael@gmx.net> On Tue, 1 Apr 2008 08:16:16 -0400, Jeffrey Tadlock wrote: > On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: > > 2) > > > > https://admin.fedoraproject.org/accounts/dump-group.cgi > > This has been replaced with this I believe: > > https://admin.fedoraproject.org/accounts/group/dump/ Thanks! Works for me. :) A little surprise was that it no longer implements the basic authentication handshake. So, instead of 401 one gets a login page when not sending credentials with the first request. From mmcgrath at redhat.com Tue Apr 1 16:49:02 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 1 Apr 2008 11:49:02 -0500 (CDT) Subject: FAS2 problems In-Reply-To: <20080401185117.acf53be2.bugs.michael@gmx.net> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> Message-ID: On Tue, 1 Apr 2008, Michael Schwendt wrote: > On Tue, 1 Apr 2008 08:16:16 -0400, Jeffrey Tadlock wrote: > > > On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: > > > 2) > > > > > > https://admin.fedoraproject.org/accounts/dump-group.cgi > > > > This has been replaced with this I believe: > > > > https://admin.fedoraproject.org/accounts/group/dump/ > > Thanks! Works for me. :) > > A little surprise was that it no longer implements the basic authentication > handshake. So, instead of 401 one gets a login page when not sending > credentials with the first request. > Side note about all this: we're slowly putting together better client libraries/api's to work with. They work now (see fasClient for a good example) but you kind of have to know how things work right now to get it up and going. -Mike From a.badger at gmail.com Tue Apr 1 16:56:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 01 Apr 2008 09:56:43 -0700 Subject: FAS2 problems In-Reply-To: <20080401185117.acf53be2.bugs.michael@gmx.net> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> Message-ID: <47F2694B.2050503@gmail.com> Michael Schwendt wrote: > On Tue, 1 Apr 2008 08:16:16 -0400, Jeffrey Tadlock wrote: > >> On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: >>> 2) >>> >>> https://admin.fedoraproject.org/accounts/dump-group.cgi >> This has been replaced with this I believe: >> >> https://admin.fedoraproject.org/accounts/group/dump/ > > Thanks! Works for me. :) > > A little surprise was that it no longer implements the basic authentication > handshake. So, instead of 401 one gets a login page when not sending > credentials with the first request. > I ran into this when showing someone the new interface last week. The way we ended up working with it was to create a small FasClient class using BaseClient from the python-fedora package. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Tue Apr 1 17:13:21 2008 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 1 Apr 2008 13:13:21 -0400 Subject: FAS2 problems In-Reply-To: <47F2694B.2050503@gmail.com> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> <47F2694B.2050503@gmail.com> Message-ID: <20080401171321.GM18510@inocybe.teonanacatl.org> Toshio Kuratomi wrote: > I ran into this when showing someone the new interface last week. > The way we ended up working with it was to create a small FasClient > class using BaseClient from the python-fedora package. That was me. Thanks Toshio. Michael, I sent you a private mail last week regarding that, since I had been using the PackageOwners.py from extras-repoclosure and noticed it was broken due to the change in dump url and usage. I'll attach that mail again (which includes a patch to make PackageOwners.py work with the new setup). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I've had a perfectly wonderful evening. But this wasn't it. -- Groucho Marx -------------- next part -------------- An embedded message was scrubbed... From: Todd Zullinger Subject: [PATCH] extras-repoclosure/PackageOwners.py using new account system dump output Date: Fri, 28 Mar 2008 13:42:19 -0400 Size: 3685 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Apr 1 17:17:11 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Apr 2008 19:17:11 +0200 Subject: FAS2 problems In-Reply-To: <47F2694B.2050503@gmail.com> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> <47F2694B.2050503@gmail.com> Message-ID: <20080401191711.940f14b0.bugs.michael@gmx.net> On Tue, 01 Apr 2008 09:56:43 -0700, Toshio Kuratomi wrote: > Michael Schwendt wrote: > > On Tue, 1 Apr 2008 08:16:16 -0400, Jeffrey Tadlock wrote: > > > >> On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: > >>> 2) > >>> > >>> https://admin.fedoraproject.org/accounts/dump-group.cgi > >> This has been replaced with this I believe: > >> > >> https://admin.fedoraproject.org/accounts/group/dump/ > > > > Thanks! Works for me. :) > > > > A little surprise was that it no longer implements the basic authentication > > handshake. So, instead of 401 one gets a login page when not sending > > credentials with the first request. > > > I ran into this when showing someone the new interface last week. The > way we ended up working with it was to create a small FasClient class > using BaseClient from the python-fedora package. Just using urllib and user:password at url was enough here. From mmcgrath at redhat.com Tue Apr 1 17:28:28 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 1 Apr 2008 12:28:28 -0500 (CDT) Subject: FAS2 problems In-Reply-To: <20080401191711.940f14b0.bugs.michael@gmx.net> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> <47F2694B.2050503@gmail.com> <20080401191711.940f14b0.bugs.michael@gmx.net> Message-ID: On Tue, 1 Apr 2008, Michael Schwendt wrote: > On Tue, 01 Apr 2008 09:56:43 -0700, Toshio Kuratomi wrote: > > > Michael Schwendt wrote: > > > On Tue, 1 Apr 2008 08:16:16 -0400, Jeffrey Tadlock wrote: > > > > > >> On Tue, Apr 1, 2008 at 8:04 AM, Michael Schwendt wrote: > > >>> 2) > > >>> > > >>> https://admin.fedoraproject.org/accounts/dump-group.cgi > > >> This has been replaced with this I believe: > > >> > > >> https://admin.fedoraproject.org/accounts/group/dump/ > > > > > > Thanks! Works for me. :) > > > > > > A little surprise was that it no longer implements the basic authentication > > > handshake. So, instead of 401 one gets a login page when not sending > > > credentials with the first request. > > > > > I ran into this when showing someone the new interface last week. The > > way we ended up working with it was to create a small FasClient class > > using BaseClient from the python-fedora package. > > Just using urllib and user:password at url was enough here. Alternatively I suspect you can pass ?user_name=user&password=password&login=Login -Mike From bugs.michael at gmx.net Tue Apr 1 17:35:07 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Apr 2008 19:35:07 +0200 Subject: FAS2 problems In-Reply-To: <20080401171321.GM18510@inocybe.teonanacatl.org> References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> <47F2694B.2050503@gmail.com> <20080401171321.GM18510@inocybe.teonanacatl.org> Message-ID: <20080401193507.d5e41fd3.bugs.michael@gmx.net> On Tue, 1 Apr 2008 13:13:21 -0400, Todd Zullinger wrote: > Toshio Kuratomi wrote: > > I ran into this when showing someone the new interface last week. > > The way we ended up working with it was to create a small FasClient > > class using BaseClient from the python-fedora package. > > That was me. Thanks Toshio. > > Michael, I sent you a private mail last week regarding that, which I answered on 17:00 UTC. ;) > I'll attach that mail again (which includes a patch to make > PackageOwners.py work with the new setup). It's fixed differently in cvs. From bugs.michael at gmx.net Tue Apr 1 18:55:48 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 1 Apr 2008 20:55:48 +0200 Subject: FAS2 problems In-Reply-To: References: <20080401140426.951bf164.bugs.michael@gmx.net> <10e0a9b00804010516v39f1728fx569186cc4b08fb84@mail.gmail.com> <20080401185117.acf53be2.bugs.michael@gmx.net> <47F2694B.2050503@gmail.com> <20080401191711.940f14b0.bugs.michael@gmx.net> Message-ID: <20080401205548.870f8504.bugs.michael@gmx.net> On Tue, 1 Apr 2008 12:28:28 -0500 (CDT), Mike McGrath wrote: > > Just using urllib and user:password at url was enough here. > > Alternatively I suspect you can pass > > ?user_name=user&password=password&login=Login If that are the correct key=value pairs for the login form, yes. That's similarly easy to do with urllib.urlencode. Form input would be a completely different authentication method, though. From skvidal at fedoraproject.org Tue Apr 1 21:51:36 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 01 Apr 2008 17:51:36 -0400 Subject: Outage Notification Torrent.fedoraproject.org - 2008-04-03 13:00 UTC Message-ID: <1207086696.15651.41.camel@cutter> There will be an outage starting at 2008-04-03 13:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-04-03 13:00 UTC UTC' Affected Services: Torrent Unaffected Services: Everything that is not torrent. Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/263 Reason for Outage: New box. Contact Information: Seth Vidal Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -sv From thinklinux.ssh at gmail.com Wed Apr 2 03:46:27 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Wed, 2 Apr 2008 09:16:27 +0530 Subject: Nagios down? Message-ID: Hi, Looks like nagios is down. https://admin.fedoraproject.org/nagios/ "Error: Could not read host and service status information!" Host down or being rebuilt? -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/SusmitShannigrahi ============================================= From mmcgrath at redhat.com Wed Apr 2 14:29:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Apr 2008 09:29:47 -0500 (CDT) Subject: Looking for team reps Message-ID: I'm looking for team reps from Ambassadors and translators for the wiki migration. Any volunteers? -Mike From sundaram at fedoraproject.org Wed Apr 2 16:22:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Apr 2008 21:52:40 +0530 Subject: Looking for team reps In-Reply-To: References: Message-ID: <47F3B2D0.80607@fedoraproject.org> Mike McGrath wrote: > I'm looking for team reps from Ambassadors and translators for the wiki > migration. Any volunteers? What would team reps do? Rahul From mmcgrath at redhat.com Wed Apr 2 16:42:00 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Apr 2008 11:42:00 -0500 (CDT) Subject: Looking for team reps In-Reply-To: <47F3B2D0.80607@fedoraproject.org> References: <47F3B2D0.80607@fedoraproject.org> Message-ID: On Wed, 2 Apr 2008, Rahul Sundaram wrote: > Mike McGrath wrote: > > I'm looking for team reps from Ambassadors and translators for the wiki > > migration. Any volunteers? > > What would team reps do? > inform their teams that the new wiki is coming and make sure everyone is aware of the needs of both sides. -Mike From couf at skynet.be Wed Apr 2 17:11:11 2008 From: couf at skynet.be (Bart Couvreur) Date: Wed, 02 Apr 2008 19:11:11 +0200 Subject: Looking for team reps In-Reply-To: References: <47F3B2D0.80607@fedoraproject.org> Message-ID: <1207156271.2992.1.camel@localhost> Op woensdag 02-04-2008 om 11:42 uur [tijdzone -0500], schreef Mike McGrath: > On Wed, 2 Apr 2008, Rahul Sundaram wrote: > > > Mike McGrath wrote: > > > I'm looking for team reps from Ambassadors and translators for the wiki > > > migration. Any volunteers? > > > > What would team reps do? > > > > inform their teams that the new wiki is coming and make sure everyone is > aware of the needs of both sides. > > -Mike Hi Mike, I can do the L10N part, what do you need from us? Bart -- Bart key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dit berichtdeel is digitaal ondertekend URL: From mmcgrath at redhat.com Wed Apr 2 18:22:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Apr 2008 13:22:48 -0500 (CDT) Subject: Looking for team reps In-Reply-To: <1207156271.2992.1.camel@localhost> References: <47F3B2D0.80607@fedoraproject.org> <1207156271.2992.1.camel@localhost> Message-ID: On Wed, 2 Apr 2008, Bart Couvreur wrote: > > Op woensdag 02-04-2008 om 11:42 uur [tijdzone -0500], schreef Mike > McGrath: > > On Wed, 2 Apr 2008, Rahul Sundaram wrote: > > > > > Mike McGrath wrote: > > > > I'm looking for team reps from Ambassadors and translators for the wiki > > > > migration. Any volunteers? > > > > > > What would team reps do? > > > > > > > inform their teams that the new wiki is coming and make sure everyone is > > aware of the needs of both sides. > > > > -Mike > > Hi Mike, > > I can do the L10N part, what do you need from us? > Go ahead and fill your name out here: http://fedoraproject.org/wiki/Infrastructure/WikiMigration And start looking through the test site for errors in your section of the wiki. -Mike From fab at fedoraproject.org Wed Apr 2 18:33:08 2008 From: fab at fedoraproject.org (Fabian Affolter) Date: Wed, 02 Apr 2008 20:33:08 +0200 Subject: Looking for team reps In-Reply-To: References: Message-ID: <47F3D164.7090209@fedoraproject.org> Mike McGrath wrote: > I'm looking for team reps from Ambassadors and translators for the wiki > migration. Any volunteers? I can help with the Ambassadors part. And I guess that the other FAmSCo members will be able to help too. Kind regards, Fabian From mmcgrath at redhat.com Wed Apr 2 18:56:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 2 Apr 2008 13:56:38 -0500 (CDT) Subject: Looking for team reps In-Reply-To: <47F3D164.7090209@fedoraproject.org> References: <47F3D164.7090209@fedoraproject.org> Message-ID: On Wed, 2 Apr 2008, Fabian Affolter wrote: > Mike McGrath wrote: > > I'm looking for team reps from Ambassadors and translators for the wiki > > migration. Any volunteers? > > I can help with the Ambassadors part. And I guess that the other FAmSCo > members will be able to help too. > > Kind regards, > > Fabian Thanks Fabian, go ahead and add your name to: http://fedoraproject.org/wiki/Infrastructure/WikiMigration -Mike From Matt_Domsch at dell.com Thu Apr 3 11:48:02 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 3 Apr 2008 06:48:02 -0500 Subject: service accounts for bz and FAS Message-ID: <20080403114802.GA23393@auslistsprd01.us.dell.com> Per http://fedoraproject.org/wiki/MattDomsch/FTBFS, I created an account in bugzilla, ftbfs at fp.o, which I will use for filing automated bug reports. In aliases.template.erb I'm routing it's mail to /dev/null. :-) However, it dawns on me that someone _could_ come along and try to create a username of "ftbfs" in FAS, which is undesirable. Should I create a new account in FAS too, to "claim" it? This account in bugzilla also needs to be in the bugzilla "editbugs" group, in order to properly file bugs (you can't set bug_state, blocked, or dependson fields via xmlrpc without being in editbugs). I've asked dkl to grant editbugs to this account, but if I created the account in FAS that would be another way to get that set. Except for the whole "signing of the CLA" for what isn't a real person's account, it's a "service" account. Which strikes me as odd. Advice on the best way to handle this, and future similar account needs? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Thu Apr 3 20:00:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 3 Apr 2008 15:00:59 -0500 (CDT) Subject: Change Freeze (IMPORTANT) Message-ID: Just a reminder to everyone that the change freeze will be taking place on April 15th. What does this mean? It means you don't make _ANY_ changes to our infrastructure without running it by the list first with an explanation of why it can't wait until after the freeze is over (April 30th) These dates are dependent on if the release slips and such. Just like last time this is a STRICTLY enforced rule. If you've got any questions. Let us know. -Mike From ricky at fedoraproject.org Thu Apr 3 22:11:02 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 3 Apr 2008 18:11:02 -0400 Subject: Meeting Log - 2008-04-03 Message-ID: <20080403221102.GA32030@Max> 15:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:03 * dgilmore is here 15:03 * daMaestro is here 15:03 * f13 15:04 -!- fugolini [n=francesc at host86-200-dynamic.7-87-r.retail.telecomitalia.it] has quit Remote closed the connection 15:05 * iWolf lurks 15:06 < mmcgrath> pretty low turnout 15:06 * mmcgrath pings some people 15:07 < mdomsch> hi 15:07 < dgilmore> mmcgrath: can we add our CA discussion to the meeting 15:07 < mmcgrath> dgilmore: sure 15:07 < abadger1999> hEY GUYS 15:07 < mmcgrath> lets start with the tickets 15:07 < dgilmore> gday abadger1999 15:07 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:07 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 15:07 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 15:07 < mmcgrath> Audio streaming for conference calls 15:07 < mmcgrath> .ticket 395 15:07 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 15:08 < mmcgrath> .any jcollie 15:08 < zodbot> mmcgrath: jcollie was last seen in #fedora-meeting 6 days, 7 hours, 20 minutes, and 27 seconds ago: *** jcollie has quit IRC ("Ex-Chat") 15:08 < mmcgrath> jcollie's not been around in a bit 15:08 < mmcgrath> so we'll skip that one for now. 15:08 < mmcgrath> .ticket 398 15:08 < zodbot> mmcgrath: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 15:08 * lmacken is here 15:08 < mmcgrath> someone in #fedora-devel mentioned there's a fix for this but I've not seen it yet 15:08 < mmcgrath> .any roland 15:08 < zodbot> mmcgrath: I have not seen roland. 15:09 < mmcgrath> roland was recently added to the sysadmin-hosted group. He may be able to better assist in this 15:09 < dgilmore> .any rmcgrath 15:09 < zodbot> dgilmore: I have not seen rmcgrath. 15:09 < mmcgrath> we'll move on for th 15:09 < mmcgrath> .ticket 446 15:09 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 15:09 < mmcgrath> skvidal: ping 15:09 -!- sebastian^ [n=sebastia at Ya1e5.y.pppool.de] has joined #fedora-meeting 15:10 < sebastian^> hi ho all 15:10 < mmcgrath> I never really heard anything more on this. 15:10 -!- buggbot [n=supybot at landfill.bugzilla.org] has quit Read error: 104 (Connection reset by peer) 15:10 < mmcgrath> IIRC we talked about adding a link to the spins.fp.o page that links to the wiki 15:10 -!- geroldka [n=Gerold at fedora/geroldka] has joined #fedora-meeting 15:10 < mmcgrath> is that what others recall? 15:10 < dgilmore> i think thats the best option 15:10 < mmcgrath> we can always go back and look at the meeting minutes. 15:11 < dgilmore> thats what we talked about 15:11 < mmcgrath> 15:11 < mmcgrath> dgilmore: would you mind getting that wiki page setup? 15:11 < dgilmore> mmcgrath: can do 15:11 < mdomsch> is spins.fp.o that hard to edit now? 15:11 < mmcgrath> solid. 15:11 -!- buggbot [n=supybot at landfill.bugzilla.org] has joined #fedora-meeting 15:11 < mmcgrath> mdomsch: not really hard, no. 15:12 < mmcgrath> alrighty, anyone have anything else on that? 15:12 < mmcgrath> next ticket 15:12 < mmcgrath> .ticket 485 15:12 < zodbot> mmcgrath: #485 (Schedule Koji DB vacuum) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/485 15:12 < mmcgrath> abadger1999: ^^ 15:13 < mdomsch> mmcgrath, then I just am curious why do it in the wiki instead of just letting the right folks edit the page directly 15:13 < mdomsch> oh well moving on 15:13 < mmcgrath> mdomsch: well, I think there were a couple of reasons. At least one of which is technical. 15:13 < abadger1999> So we just need to do a complete vacuumof koji. 15:13 < mmcgrath> the other was more about hosting and stuff. How do we know the difference between an "official" spin and a non official one? Do we care? 15:13 < mmcgrath> abadger1999: how long will it take? 15:14 < abadger1999> It will probably make kojia bit slow. 15:14 < abadger1999> Unknown how long it will take but 15:14 < mdomsch> mmcgrath, official ones are blessed by the board, hosting is determined by rel-eng based on space available determined by infra 15:14 < abadger1999> Lasttime we attemptedthis, did it go for longerthan 24 hours? 15:14 < mmcgrath> abadger1999: and it does not require a lock right? 15:14 < abadger1999> Correct. 15:15 < mmcgrath> mdomsch: but how do the users figure it out if they're all listed in the same place? 15:15 < abadger1999> But it could slow things down. 15:15 < mmcgrath> abadger1999: is that something we could just start on Sat? 15:15 < mmcgrath> and hope its done by monday? 15:15 < abadger1999> We can definitely startit. 15:15 < mmcgrath> f13: ping 15:15 < mmcgrath> you guys have any major rebuilds planned for this weekend? 15:15 < mdomsch> listed != hosted :-) 15:16 < dgilmore> mmcgrath: i moved the sparc postgres to 8.3 this week 15:16 < mmcgrath> dgilmore: how'd that go? 15:16 < dgilmore> mmcgrath: ill see how it works since autovacuum is supposed to work 15:16 < f13> mmcgrath: this weekend? Not that I know of, except that it's the last weekend before the Final Freeze for Fedora 9 15:17 < mmcgrath> dgilmore: excellent. 15:17 < dgilmore> mmcgrath: it transitioned smoothly, you have to do a dump restore to change versions 15:17 < mmcgrath> f13: we're thinking about running a vacuum on the db so we stop getting notices about it. 15:17 < mmcgrath> and because we're running out of transactions 15:17 < dgilmore> mmcgrath: i think this weekend is fine 15:17 < f13> hrm. 15:18 < f13> it 15:18 < mmcgrath> dgilmore: 15:18 < f13> it'll just make things a bit slower right, not break anything? 15:18 < dgilmore> f13: yes 15:18 < mmcgrath> f13: correct. 15:18 < abadger1999> f13: Correct. 15:18 < f13> ok... 15:18 < f13> I reserve the right to be bitchy if something falls over and holds up Fedora 9 builds (: 15:19 * abadger1999 notes that the warnings start when we hit half way so we could go for a bit longer if we have to. 15:19 < mmcgrath> abadger1999: does this weekend work for you or would you rather me do it? 15:19 < mmcgrath> abadger1999: and how the hell did we run out of FAS tranasctions so quick :) ? 15:19 -!- spoleeba [n=one at fedora/Jef] has quit "Leaving" 15:20 < abadger1999> I can do it this weekend 15:20 < abadger1999> FAS is kinda worrisome but at leastit's a small db. 15:20 < mmcgrath> yeah 15:20 < mmcgrath> abadger1999: solid, well let me know if you need anything 15:21 < mbonnet> abadger1999: remember to disable the other vacuums while it's going 15:21 < abadger1999> Right. mbonnet -- only for that db, though, correct? 15:21 < mbonnet> abadger1999: correct 15:21 < abadger1999> Cool. I think we're all set on that then. 15:22 < mbonnet> abadger1999: also, don't bother with the analyze, since that can be done on a table-by-table basis later 15:22 < abadger1999> 15:22 -!- Southern_Gentlem [n=notfred at unaffiliated/southerngentlem/x-2894754] has joined #fedora-meeting 15:22 < mmcgrath> cool 15:22 < mmcgrath> alrighty, anyone have anything else on that? 15:23 < dgilmore> not I 15:23 < mmcgrath> cool, then we're done with the tickets 15:23 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Certificates 15:23 -!- spoleeba [n=one at fedora/Jef] has joined #fedora-meeting 15:23 < mmcgrath> dgilmore: want to take the floor on that one? 15:23 < dgilmore> mmcgrath: :) yep 15:24 < dgilmore> so looking at all the options for setting up and managing our certificate infrastructure 15:24 < dgilmore> all of them have definete downsides 15:25 < dgilmore> I really dont want to write our own 15:25 < dgilmore> i think its too much effort for too little gain 15:25 < mdomsch> dgilmore, agreed 15:25 -!- kital [n=Joerg_Si at fedora/kital] has joined #fedora-meeting 15:25 < dgilmore> i'm thinking that we should try make dogfood work 15:26 < dgilmore> i have spoken with the devs of it and they commited to helping us 15:26 < skvidal> mmcgrath: pong 15:26 < dgilmore> dog tag 15:26 < skvidal> sorry, was in another desktop 15:26 < mmcgrath> skvidal: I forget what I was going to ask :) 15:26 < skvidal> torrent? 15:26 < mmcgrath> dgilmore: is it in Fedora already? 15:26 < mmcgrath> skvidal: maybe 15:26 < dgilmore> mmcgrath: not yet 15:27 < dgilmore> mmcgrath: however none of the options is 15:27 < dgilmore> one of them requires jboss 15:27 < dgilmore> so it will be a huge task to get in 15:27 < dgilmore> dogtag has some pieces in fedora 15:27 < dgilmore> it uses fedora-ds for storage 15:27 -!- fab_away [n=bellet at bellet.info] has quit No route to host 15:28 < dgilmore> the option using a relational db uses jboss 15:28 < dgilmore> i think it was openca 15:28 < dgilmore> one of the other options uses openldap 15:28 < mmcgrath> So whats the scope of this project? We're looking to give and revoke certificates to our users. 15:28 < mmcgrath> will this also sign our VPN and builder certs? 15:28 < dgilmore> yes 15:29 < mmcgrath> will this have anything to do with package signing? 15:29 < dgilmore> nothing to do with packag signing 15:29 < dgilmore> so we will need to setup the ca 15:29 < mmcgrath> Solid, so what do you need to get a proof of concept setup? 15:30 < dgilmore> test that when we revoke certs apps honour the revokation 15:30 < dgilmore> probably will need 2 or 3 vm's 15:30 < mmcgrath> k, the german box telia1 is up 15:30 < dgilmore> setup as many apps as we can 15:30 < mmcgrath> .ping telia1.fedoraproject.org 15:30 < zodbot> pong 15:31 < mmcgrath> We're going to stick one app and one proxy server out there, the rest can be used for test. 15:31 < mmcgrath> we've got a /28 for it. 15:31 < dgilmore> :) nice 15:31 < mmcgrath> if you want to virt-inst some guests over there, have at it. 15:31 < dgilmore> ok will do 15:32 < dgilmore> I'm going to need some help getting things setup and running 15:32 < dgilmore> and testing 15:32 -!- geroldka [n=Gerold at fedora/geroldka] has quit "Leaving" 15:32 < dgilmore> in the end all users will need new certs. as will all builders and vpn endpoints 15:32 < mmcgrath> I'm a little confused on how this will tie in to FAS2 (if it even will) 15:32 < mmcgrath> Like, where will users go to actually get their cert? 15:33 < dgilmore> they will go to fas2 15:33 < mmcgrath> perhaps we'll have a better view after we get it all setup 15:33 < dgilmore> but fas2 will request it from the ca 15:33 < iWolf> dgilmore: i might have time to help with some setup if you need it. 15:33 < dgilmore> iWolf: thanks 15:34 < mmcgrath> solid. 15:34 < mmcgrath> dgilmore: you have anything else on that front? 15:34 < dgilmore> so thats how i think we should procede 15:34 < dgilmore> mmcgrath: i think thats it 15:35 < mmcgrath> solid 15:35 < mmcgrath> dgilmore: sounds good, let me know if you need anything 15:35 < mmcgrath> Movin on 15:35 < dgilmore> mmcgrath: willd o 15:35 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Torrent 15:35 < mmcgrath> skvidal: mind giving a quick overview of what we did, why we did it and how much space we've got left? 15:36 < skvidal> yes 15:36 < skvidal> okay 15:36 < skvidal> 1. eventually got torrent1.fp.o to stay up and online 15:36 < skvidal> 2. allocated 400gb of the 425gb available to /srv of torrent 15:36 < skvidal> 3. installed bittorrent 5.2.0 - had it fall over every 20 minutes or so, 15:37 < skvidal> 4. cursed a lot, attempted to fix 15:37 < skvidal> 5. found it was just not reliable 15:37 < skvidal> 6. rebuilt bt 4.4.0 and installed it 15:37 < skvidal> 7. had it fall over , while not a lot, a fair bit, 15:37 < skvidal> 8. figured out that 4.4.0 and modern python-twisted don't get along 15:37 < skvidal> 9. disable twisted 15:37 < skvidal> 10. restart bttrack 15:37 < skvidal> 11. profit 15:38 < mmcgrath> all in all though we're in good shape now? 15:38 < skvidal> 12. removed zod and bordeaux (among other crap like fedora7-rc2) from torrents 15:38 < mmcgrath> eww 15:38 < skvidal> currently there are 203G remaining 15:38 < skvidal> and it appears to be running correctly 15:38 < skvidal> time and f9 will tell if it is truly reliable 15:38 < mmcgrath> 15:38 < mmcgrath> skvidal: thanks! 15:39 < skvidal> but atm it is more reliable than it was before 15:39 < mmcgrath> excellent. 15:39 < mmcgrath> anything else? 15:39 < skvidal> I'm updating the SOP, now 15:39 < skvidal> oh and 15:39 < skvidal> if anyone wants a project that will make them instantly excellent 15:39 < skvidal> fork bt 4.4.0 and maintain it/make it sane 15:40 < skvidal> hell, even if you only made it a server (bttrack/bttseed) you'd be a hit 15:40 < skvidal> that's all 15:40 < mmcgrath> :) 15:40 < mmcgrath> skvidal isn't kidding btw :) 15:40 < mmcgrath> alrighty. Movin on 15:40 < dgilmore> skvidal: what is the deal with bt 5.x? 15:41 < skvidal> dgilmore: it would either run out of files (even when I increased it to ludicrous amounts) or it would stop sending the /announce page, at all. 15:41 < skvidal> and then 5.2.0 is the dead end 15:41 < skvidal> bittorrent.com stopped the open source releases 15:41 < dgilmore> :( didnt they change the license? 15:41 < skvidal> oh they're chock full of evil 15:42 < mmcgrath> pure evil 15:42 < mmcgrath> ok, movin on 15:42 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Me gone tomorrow and saturday. 15:43 < mmcgrath> I've got a conference where I'm representin' Red Hat and Fedora. 15:43 < mmcgrath> I'll be back on Sunday. 15:43 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:43 < mdomsch> enjoy 15:43 < mmcgrath> Ok, so thats really all we had planned for this meeting. 15:43 < mmcgrath> The wiki migration is moving along but there's still TONS to be done for those of you python coders interested in helping, the migration script could always use work. 15:44 < mmcgrath> I'm also working on getting the docbooko stuff all figured out. 15:44 < mmcgrath> ricky: you around by chance? 15:45 < mmcgrath> guess not. 15:45 < mmcgrath> we're still blocking a bit on FAS2 and OpenID but I'm pretty confident that'll be in good shape. 15:45 < mmcgrath> Alrighty, anyone have anything else they'd like to discuss? If not I'll close the meeting. 15:45 < dgilmore> mmcgrath: making fas a openid provider? 15:46 * dgilmore is done 15:46 < mmcgrath> dgilmore: yeah 15:46 < poelcat> mmcgrath: what is the targeted golive date for the new wiki? 15:46 < iWolf> mmcgrath: where is the migration script for the wiki? 15:46 < mmcgrath> poelcat: don't have one yet but it will be after F9 ships. Hopefully by a week or two. 15:46 < poelcat> okay 15:46 < mmcgrath> iWolf: git.fedorahosted.org/git/fedora-infrastructure.git/scripts/ 15:47 < iWolf> mmcgrath: thanks! 15:47 < mmcgrath> alrighty, if no one has anything else we'll close the meeting in 30 15:47 < mmcgrath> 15 15:47 < mdomsch> mmcgrath, when is freeze for f9? 15:47 < mmcgrath> mdomsch: ahh, good question. 15:48 * mmcgrath looks. 15:48 * mdomsch sneaks in under the wire 15:48 < mmcgrath> mdomsch: well last time we did a 2 week freeze IIRC. 15:48 -!- gkrpan [n=greg at c-71-56-252-37.hsd1.co.comcast.net] has joined #fedora-meeting 15:49 < mmcgrath> f13: did you want a longer change freeze this time around? 15:49 < mdomsch> yes, and that seemed to work pretty well 15:49 < mmcgrath> we could do a partial change freeze on the 8th followed by a full freeze on the 15th? 15:49 * mmcgrath doesn't know what a partial change freeze is but we could come up with something. 15:49 < mmcgrath> otherwise I'm fine with just doing the full freeze on the 15th. 15:49 < mdomsch> everyone's got the 29th free for an all-hands-on-deck, right? 15:50 < mmcgrath> mdomsch: I'll send a reminder out to everyone and about the change freeze. 15:50 < f13> mmcgrath: I think jsut full freeze on the 15th is fine, but I would like veto powers on any proposed changes leading up to then 15:50 < f13> well, I'd like releng to thave that, not me specifically 15:51 < mmcgrath> f13: hmm, I don't see any reason that wouldn't work. veto / revert powers. Plenty of changes go through without approval. 15:51 < f13> I think those two sentences contradict eachother 15:52 -!- giallu [n=giallu at 81-174-46-50.dynamic.ngi.it] has joined #fedora-meeting 15:52 < mmcgrath> f13: they do, the fact is you can't have veto power on something that doesn't go through an approval process. But I'm happy to give it to you :) 15:52 < mmcgrath> f13: If you've got a problem with a change though bring it to the list, I'm sure we can all work something out. 15:52 < mdomsch> mmcgrath, one more - soc status on download1 routing? 15:53 < mmcgrath> mdomsch: you're guess is as good as mine on that one. They don't tell me anything / keep me up to date on anything. 15:53 < mdomsch> mgalgoci was going to stir up trouble on Monday morning 15:53 < mmcgrath> I can follow up in the ticket and let tom know. 15:53 < mdomsch> as it stands, we won't be able to feed our tier 1 mirrors, much less anyone else 15:53 < mmcgrath> mdomsch: do you know when we lost that link yet? 15:53 < mdomsch> weeks ago 15:53 < mmcgrath> I requested that information from the soc and heard nothing. 15:53 < mdomsch> I remember seeing a note at the time, thinking it would be fixed in a few days 15:54 < mmcgrath> ok. I'm going to bring it to my manager because A) its constant bs with the soc and I'm tired of it. and B) they never bothered to notify us. 15:54 < mdomsch> check mirror-list-d archives, they may have sent something there... 15:54 < mmcgrath> k, I'll double check there then. 15:54 < mdomsch> in any case, we've _got_ to get the bits to ibiblio, else we're scrod 15:54 < mmcgrath> That I'm sure we can do. 15:54 < mdomsch> (past pluperfect of screw) 15:54 < f13> mmcgrath: ok, so maybe the concept of a soft freeze is where you ask before making any changes, and at that point I'd have the ability to say no. 15:55 < f13> mmcgrath: at the hard freeze date, just no changes at all unless it's fixing things 15:55 < mmcgrath> f13: why not just stick with the system we put in place last release? It seemed to work just fine? 15:55 < f13> *shrug* sure, we could do that 15:55 * mmcgrath just doesn't want to complicate it unless there's a reason to. We've got a good team of people there. 15:56 < mmcgrath> Alrighty, anyone have anything else to discuss? If not we'll close in 30 15:56 < mmcgrath> 15 15:57 < f13> nod 15:57 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Fri Apr 4 00:16:53 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 03 Apr 2008 20:16:53 -0400 Subject: torrent migration, reversed Message-ID: <1207268213.15651.110.camel@cutter> Hi folks, I attempted to migrate the torrent to the new server today. That didn't pan out First, the new torrent version didn't work well under any significant load. It worked okay in the tests I had run, but not when hit by all of our users. I worked around this by playing with the version a bit. It was working for a while. Then it died b/c, apparently, the machine it is hosted on died. I've migrated the hostname back to the old machine and brought the old torrent back online. I've also requested the hardware be replaced in the new machine. As soon as we can get a stable machine I'll attempt the migration, again. Thanks, -sv -- I only speak for me. From a.badger at gmail.com Fri Apr 4 04:45:58 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 03 Apr 2008 21:45:58 -0700 Subject: Is someone rebooting app5? Message-ID: <47F5B286.6040602@gmail.com> Did I miss a memo or is there a problem with app5? It seems to be rebooting pretty frequently. (The Xen host is not rebooting, just this guest) /var/log/messages:: [...] Apr 3 21:27:28 app5 kernel: Linux version 2.6.18-8.el5xen Apr 3 22:23:57 app5 kernel: Linux version 2.6.18-8.el5xen Apr 3 23:04:08 app5 kernel: Linux version 2.6.18-8.el5xen Apr 3 23:22:41 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 00:50:52 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 01:40:06 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 02:11:59 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 02:56:31 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 03:17:34 app5 kernel: Linux version 2.6.18-8.el5xen Apr 4 04:31:15 app5 kernel: Linux version 2.6.18-8.el5xen Logs on xen9 Show this:: [2008-04-04 03:17:07 xend.XendDomainInfo 3444] DEBUG (XendDomainInfo:988) XendDomainInfo.handleShutdownWatch [2008-04-04 04:30:42 xend.XendDomainInfo 3444] WARNING (XendDomainInfo:923) Domain has crashed: name=app5 id=53. [2008-04-04 04:30:42 xend.XendDomainInfo 3444] DEBUG (XendDomainInfo:1566) XendDomainInfo.destroyDomain(53) Services on app5 are load balanced on app4 so we aren't losing a service when this happens. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Fri Apr 4 15:26:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 4 Apr 2008 10:26:18 -0500 (CDT) Subject: Is someone rebooting app5? In-Reply-To: <47F5B286.6040602@gmail.com> References: <47F5B286.6040602@gmail.com> Message-ID: On Thu, 3 Apr 2008, Toshio Kuratomi wrote: > Did I miss a memo or is there a problem with app5? It seems to be rebooting > pretty frequently. (The Xen host is not rebooting, just this guest) > > /var/log/messages:: > [...] > Apr 3 21:27:28 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 3 22:23:57 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 3 23:04:08 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 3 23:22:41 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 00:50:52 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 01:40:06 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 02:11:59 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 02:56:31 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 03:17:34 app5 kernel: Linux version 2.6.18-8.el5xen > Apr 4 04:31:15 app5 kernel: Linux version 2.6.18-8.el5xen > > Logs on xen9 Show this:: > [2008-04-04 03:17:07 xend.XendDomainInfo 3444] DEBUG (XendDomainInfo:988) > XendDomainInfo.handleShutdownWatch > [2008-04-04 04:30:42 xend.XendDomainInfo 3444] WARNING (XendDomainInfo:923) > Domain has crashed: name=app5 id=53. > [2008-04-04 04:30:42 xend.XendDomainInfo 3444] DEBUG (XendDomainInfo:1566) > XendDomainInfo.destroyDomain(53) > > Services on app5 are load balanced on app4 so we aren't losing a service when > this happens. Interesting, I don't think anyone's rebooting it but I just got on to see a 2 minute uptime. That machine was recently rebuilt (like a couple of days ago) so its possible something went wrong or there's an issue in a newer kernel that its running but other boxes aren't. -Mike > From Matt_Domsch at dell.com Sun Apr 6 15:42:00 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 6 Apr 2008 10:42:00 -0500 Subject: download2.fedora.redhat.com is behind; download3 overloaded Message-ID: <20080406154200.GA24677@humbolt.us.dell.com> Since download1 DNS is pointing at download3 right now, rsync connections to that box often fail. I think it's overloaded. Recall download3 is in PHX. Download2 is running "behind" in its snap-mirroring. Or at least that's the impression one gets when rsyncing from it - after several several hours, it still hasn't finished picking up all the rawhide pushes from each day. It has been this way since at least mid last week; I don't have better statistics than this. As rawhide is now pushed from netapp in PHX, I suspect the overload of download3 is also causing bandwidth to be unavailable for snap-mirroring from the netapp in PHX to download2 in TPA. As it stands, I am extremely worried about the Fedora 9 launch scheduled for 29 April, data to flow to the mirrors starting ~24 April if all goes well. That's about 2.5 weeks from now. If the unavailability of download1 in RDU from Internet2 continues, we won't be able to get the bits to the mirrors. While we have intentionally hidden download.fedora.redhat.com from the published mirrorlists (since the Fedora 8 launch), if our mirrors don't get the bits, users _will_ come searching for them, and _will_ find them on download.fedora.redhat.com. I would hate to have a repeat of the Fedora 6 launch fiasco, where we knocked redhat.com offline for a week. What can we do, immediately, to get download1 again reachable over I2, even if it's only via static routes to fedora-archives.ibiblio.org? 9 of our 10 "Tier 1" mirrors reach us over I2. We can direct them all to fedora-archives.ibiblio.org, if we can get the content over to them in a timely manner. (fwiw, 3 of the 4 mirrors.kernel.org servers aren't on I2, but all our other Tier 1 mirrors are.) I suspect this will resolve the overload of download3, and the network bandwidth challenge (which I presume exists) which will resolve the snap-mirror to download2. Thanks, Matt Fedora Mirror Wrangler, and one who doesn't want to see the fallout of knocking redhat.com offline for a week again... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From roland at redhat.com Sun Apr 6 21:54:43 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 6 Apr 2008 14:54:43 -0700 (PDT) Subject: fedora-infrastructure.git Message-ID: <20080406215443.114F426F990@magilla.localdomain> What is the relationship between git://git.fedorahosted.org/git/fedora-infrastructure.git and the configs/system scripts in puppet1:/cvs/puppet? If I want to commit a new version of a script and then get it deployed, what is the procedure? Thanks, Roland From mmcgrath at redhat.com Mon Apr 7 00:36:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 6 Apr 2008 19:36:56 -0500 (CDT) Subject: fedora-infrastructure.git In-Reply-To: <20080406215443.114F426F990@magilla.localdomain> References: <20080406215443.114F426F990@magilla.localdomain> Message-ID: On Sun, 6 Apr 2008, Roland McGrath wrote: > What is the relationship between > git://git.fedorahosted.org/git/fedora-infrastructure.git > and the configs/system scripts in puppet1:/cvs/puppet? > > If I want to commit a new version of a script and then get it deployed, > what is the procedure? > They're not directly related but in our case if its something that could be useful outside of Infrastructure we typically stick a copy in fedora-infrastructure.git. This is sub optimal because then we've got a copy of the script in two locations. Ideally we'd want puppet to pull directly from the fedora-infrastructure.git repo for such scripts but the work hasn't been done yet to see what that would take (anyone with access is welcome to show us how its done, just stick it in the /wiki/Infrastructure/SOP/Puppet page. -Mike From Matt_Domsch at Dell.com Mon Apr 7 14:44:21 2008 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Mon, 7 Apr 2008 09:44:21 -0500 Subject: download*.fedora.redhat.com rsyncd change request Message-ID: On download*.fedora.redhat.com, please make the following changes to the rsyncd.conf file. 1) add a motd file, with content such as: Fedora Master Mirror Servers See http://fedoraproject.org/wiki/Infrastructure/Mirroring for instructions. Modules for Fedora Core and Extras have been removed, as this content is no longer updated. See the instructions above for how to mirror current content. 2) remove fedora-linux-core* and fedora-linux-extras rsync modules. In doing so, we will hopefully be put back in contact with the ~80 mirrors who never made the transition from core/ to releases/. Thanks, Matt Domsch Fedora Mirror Wrangler -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From stickster at gmail.com Wed Apr 9 13:38:02 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Apr 2008 13:38:02 +0000 Subject: Possible new CLA Message-ID: <1207748282.5428.124.camel@localhost.localdomain> There is a draft of a new CLA being circulated at FreeIPA: https://www.redhat.com/archives/freeipa-devel/2008-April/msg00052.html http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf I've asked Legal for a summary of what's changed and why, and an answer to whether all Fedora contributors would need to re-execute this agreement. (I'm betting the answer to the last question is "yes," but that's just an educated guess.) I believe the changes to be minor, mainly to eliminate loopholes and to make this process less onerous in the future, but I'll wait for more information. Ricky Zhou tells me that our CLA signing information is kept in the form of a log table, not a simple date field. AIUI then, we have the ability to find out what CLAs have been executed over the life of an account. If I'm correct about that, I want to say first, thanks for a really good design. :-) Second, since a new CLA is a possibility -- I just want to confirm that we are not *overwriting* old CLA data, i.e. we would maintain a history that user "johndoe" signed a CLA on 2007-10-15 and then again on 2008-04-28. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Wed Apr 9 14:51:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 9 Apr 2008 09:51:41 -0500 (CDT) Subject: Possible new CLA In-Reply-To: <1207748282.5428.124.camel@localhost.localdomain> References: <1207748282.5428.124.camel@localhost.localdomain> Message-ID: On Wed, 9 Apr 2008, Paul W. Frields wrote: > There is a draft of a new CLA being circulated at FreeIPA: > > https://www.redhat.com/archives/freeipa-devel/2008-April/msg00052.html > http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf > > I've asked Legal for a summary of what's changed and why, and an answer > to whether all Fedora contributors would need to re-execute this > agreement. (I'm betting the answer to the last question is "yes," but > that's just an educated guess.) I believe the changes to be minor, > mainly to eliminate loopholes and to make this process less onerous in > the future, but I'll wait for more information. > > Ricky Zhou tells me that our CLA signing information is kept in the form > of a log table, not a simple date field. AIUI then, we have the ability > to find out what CLAs have been executed over the life of an account. > > If I'm correct about that, I want to say first, thanks for a really good > design. :-) This is only true for FAS2, not FAS1 I think. > Second, since a new CLA is a possibility -- I just want to confirm that > we are not *overwriting* old CLA data, i.e. we would maintain a history > that user "johndoe" signed a CLA on 2007-10-15 and then again on > 2008-04-28. AFAIK the cla gets signed and a copy of it gets forwarded on to some legal address. We might want to contact the owner of that address (maybe spot? maybe greg?) and see if that mailbox is still full of cla signatures. -Mike From stickster at gmail.com Wed Apr 9 15:43:22 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Apr 2008 15:43:22 +0000 Subject: Possible new CLA In-Reply-To: References: <1207748282.5428.124.camel@localhost.localdomain> Message-ID: <1207755802.5428.214.camel@localhost.localdomain> On Wed, 2008-04-09 at 09:51 -0500, Mike McGrath wrote: > On Wed, 9 Apr 2008, Paul W. Frields wrote: > > > There is a draft of a new CLA being circulated at FreeIPA: > > > > https://www.redhat.com/archives/freeipa-devel/2008-April/msg00052.html > > http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf > > > > I've asked Legal for a summary of what's changed and why, and an answer > > to whether all Fedora contributors would need to re-execute this > > agreement. (I'm betting the answer to the last question is "yes," but > > that's just an educated guess.) I believe the changes to be minor, > > mainly to eliminate loopholes and to make this process less onerous in > > the future, but I'll wait for more information. > > > > Ricky Zhou tells me that our CLA signing information is kept in the form > > of a log table, not a simple date field. AIUI then, we have the ability > > to find out what CLAs have been executed over the life of an account. > > > > If I'm correct about that, I want to say first, thanks for a really good > > design. :-) > > This is only true for FAS2, not FAS1 I think. > > > Second, since a new CLA is a possibility -- I just want to confirm that > > we are not *overwriting* old CLA data, i.e. we would maintain a history > > that user "johndoe" signed a CLA on 2007-10-15 and then again on > > 2008-04-28. > > AFAIK the cla gets signed and a copy of it gets forwarded on to some legal > address. We might want to contact the owner of that address (maybe spot? > maybe greg?) and see if that mailbox is still full of cla signatures. I think it's spot. He'll see this and confirm or deny as needed. :-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stickster at gmail.com Wed Apr 9 21:58:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Apr 2008 17:58:58 -0400 Subject: [Fedora-legal-list] Re: Possible new CLA In-Reply-To: <1207756691.3000.20.camel@localhost.localdomain> References: <1207748282.5428.124.camel@localhost.localdomain> <1207755802.5428.214.camel@localhost.localdomain> <1207756691.3000.20.camel@localhost.localdomain> Message-ID: <1207778338.5428.273.camel@localhost.localdomain> On Wed, 2008-04-09 at 11:58 -0400, Tom "spot" Callaway wrote: > On Wed, 2008-04-09 at 15:43 +0000, Paul W. Frields wrote: > > > I think it's spot. He'll see this and confirm or deny as needed. :-) > > CLAs come into my inbox. I hadn't been keeping them, just sanity > checking them. If I understand what Ricky meant by "log table" correctly, we have a list of dates that we can tie to account names. If someone could confirm this who understands the bits involved, that would be great. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ricky at fedoraproject.org Wed Apr 9 22:04:11 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 9 Apr 2008 18:04:11 -0400 Subject: [Fedora-legal-list] Re: Possible new CLA In-Reply-To: <1207778338.5428.273.camel@localhost.localdomain> References: <1207748282.5428.124.camel@localhost.localdomain> <1207755802.5428.214.camel@localhost.localdomain> <1207756691.3000.20.camel@localhost.localdomain> <1207778338.5428.273.camel@localhost.localdomain> Message-ID: <20080409220411.GH24783@Max> On 2008-04-09 05:58:58 PM, Paul W. Frields wrote: > If I understand what Ricky meant by "log table" correctly, we have a > list of dates that we can tie to account names. If someone could > confirm this who understands the bits involved, that would be great. Exactly. It just links a user to a date and an action (such as signing the CLA). Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Apr 9 22:11:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 9 Apr 2008 17:11:09 -0500 (CDT) Subject: [Fedora-legal-list] Re: Possible new CLA In-Reply-To: <1207778338.5428.273.camel@localhost.localdomain> References: <1207748282.5428.124.camel@localhost.localdomain> <1207755802.5428.214.camel@localhost.localdomain> <1207756691.3000.20.camel@localhost.localdomain> <1207778338.5428.273.camel@localhost.localdomain> Message-ID: On Wed, 9 Apr 2008, Paul W. Frields wrote: > On Wed, 2008-04-09 at 11:58 -0400, Tom "spot" Callaway wrote: > > On Wed, 2008-04-09 at 15:43 +0000, Paul W. Frields wrote: > > > > > I think it's spot. He'll see this and confirm or deny as needed. :-) > > > > CLAs come into my inbox. I hadn't been keeping them, just sanity > > checking them. > > If I understand what Ricky meant by "log table" correctly, we have a > list of dates that we can tie to account names. If someone could > confirm this who understands the bits involved, that would be great. > I think we'd be covered. WE know when oldies like myself signed the CLA because it tracks when I joined cla_done. If I re-sign something I don't think I'll be joining cla_done and the new cla agreement should show up in the log table. -Mike From dennis at ausil.us Thu Apr 10 20:17:23 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 10 Apr 2008 15:17:23 -0500 Subject: Fedora CA Project In-Reply-To: <200803251804.21899.dennis@ausil.us> References: <200803251804.21899.dennis@ausil.us> Message-ID: <200804101517.28389.dennis@ausil.us> On Tuesday 25 March 2008, Dennis Gilmore wrote: > We have come to the realisation that this has to be done sooner rather than > later. So i'm putting out a call for help and for feedback. > > We need to revamp the CA infrastructure used in Fedora. > > This is where Id like to see us go. > > Publish a Certificate Revocation list so that all apps can check for > revoked certs > > Have users able to revoke their own cert > Have user certs be revoked when they request a new cert > Have admins able to create/revoke certs > > Their are 2 types of certificates currently handled by 2 CA's I really > want to use a single CA for all: > > Type 1) user certs. used for plague/koji/cvs upload access. there is > work underway to use these for other fedora web based apps also. > > Type 2) Builders, kojira, internal service authentication. > > > Products to be evaluated: > > http://pki.fedoraproject.org/wiki/PKI_Main_Page > https://www.openca.org/ > http://ejbca.sourceforge.net/ > Something custom > > FAS will need modification to work with the new framework. I also want to > allow fedora-packager-setup to grab the cert directly rather than having > the user manually do it. probably with a flag for when to get a new cert. > > All users will need to get new user certs when we make the change. as well > as koji hub, all builders, koji garbage collection, bodhi, It would also be > a good time to deploy ssl auth for other apps. > > We have a ticket https://fedorahosted.org/fedora-infrastructure/ticket/466 > > Please make suggestions for other apps we could use, also ideas for making > the workflow better. > > So this is a brief overview of whats needed. Im going to open the floor > for a week for open discussion on how we should best do this. > > Dennis To follow up on this. Im going to be looking at dogtag first. Ive had a promise from them to help us when we have issues. OpenCA seems to have stalled development wise. ejbca has a very heavy footprint. something Custom i think is too big of a task. So people wanting to help with setting up, implementing and testing please raise your hands now. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From wakko666 at gmail.com Thu Apr 10 20:28:32 2008 From: wakko666 at gmail.com (Brett Lentz) Date: Thu, 10 Apr 2008 20:28:32 +0000 Subject: Fedora CA Project In-Reply-To: <200804101517.28389.dennis@ausil.us> References: <200803251804.21899.dennis@ausil.us> <200804101517.28389.dennis@ausil.us> Message-ID: <1207859312.3647.24.camel@blentz> On Thu, 2008-04-10 at 15:17 -0500, Dennis Gilmore wrote: > To follow up on this. Im going to be looking at dogtag first. Ive had a > promise from them to help us when we have issues. > > OpenCA seems to have stalled development wise. > > ejbca has a very heavy footprint. > > something Custom i think is too big of a task. > > So people wanting to help with setting up, implementing and testing please > raise your hands now. > > Dennis > If Dogtag doesn't pan out, I'm willing to help with ejbca. I'm already familiar with it. ---Brett. Are you tired of being a crash test dummy for Microsoft? Discover Linux. -- Gareth Barnard From jmtaylor90 at gmail.com Thu Apr 10 20:38:18 2008 From: jmtaylor90 at gmail.com (Jason) Date: Thu, 10 Apr 2008 16:38:18 -0400 Subject: Fedora CA Project In-Reply-To: <200804101517.28389.dennis@ausil.us> References: <200803251804.21899.dennis@ausil.us> <200804101517.28389.dennis@ausil.us> Message-ID: <1207859898.7501.0.camel@bruiser.localdomain> On Thu, 2008-04-10 at 15:17 -0500, Dennis Gilmore wrote: > On Tuesday 25 March 2008, Dennis Gilmore wrote: > > We have come to the realisation that this has to be done sooner rather than > > later. So i'm putting out a call for help and for feedback. > > > > We need to revamp the CA infrastructure used in Fedora. > > > > This is where Id like to see us go. > > > > Publish a Certificate Revocation list so that all apps can check for > > revoked certs > > > > Have users able to revoke their own cert > > Have user certs be revoked when they request a new cert > > Have admins able to create/revoke certs > > > > Their are 2 types of certificates currently handled by 2 CA's I really > > want to use a single CA for all: > > > > Type 1) user certs. used for plague/koji/cvs upload access. there is > > work underway to use these for other fedora web based apps also. > > > > Type 2) Builders, kojira, internal service authentication. > > > > > > Products to be evaluated: > > > > http://pki.fedoraproject.org/wiki/PKI_Main_Page > > https://www.openca.org/ > > http://ejbca.sourceforge.net/ > > Something custom > > > > FAS will need modification to work with the new framework. I also want to > > allow fedora-packager-setup to grab the cert directly rather than having > > the user manually do it. probably with a flag for when to get a new cert. > > > > All users will need to get new user certs when we make the change. as well > > as koji hub, all builders, koji garbage collection, bodhi, It would also be > > a good time to deploy ssl auth for other apps. > > > > We have a ticket https://fedorahosted.org/fedora-infrastructure/ticket/466 > > > > Please make suggestions for other apps we could use, also ideas for making > > the workflow better. > > > > So this is a brief overview of whats needed. Im going to open the floor > > for a week for open discussion on how we should best do this. > > > > Dennis > > To follow up on this. Im going to be looking at dogtag first. Ive had a > promise from them to help us when we have issues. > > OpenCA seems to have stalled development wise. > > ejbca has a very heavy footprint. > > something Custom i think is too big of a task. > > So people wanting to help with setting up, implementing and testing please > raise your hands now. > > Dennis I would be willing to help. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ricky at fedoraproject.org Thu Apr 10 23:18:15 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 10 Apr 2008 19:18:15 -0400 Subject: Meeting Log - 2008-04-10 Message-ID: <20080410231815.GB11733@Max> 15:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:01 * yingbull is. 15:01 < mmcgrath> Alrighty everyone, who's around? 15:01 * warren here 15:01 * skvidal is here 15:01 * notting is here 15:01 < mmcgrath> jcollie: you around? 15:02 < jcollie> yup 15:02 < ivazquez> Pong. 15:02 < mmcgrath> cool, lets get started then 15:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets 15:02 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 15:02 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 15:02 * MostafaDaneshvar is there 15:02 < mmcgrath> First ticket: 15:02 < mmcgrath> .ticket 395 15:02 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 15:02 < mmcgrath> jcollie: whats the latest? 15:02 < warren> mmcgrath: is agenda set in stone? I want to add s/cvsextras/packager/ after F9 release and next convenient scheduled outage. 15:03 < mmcgrath> warren: not at all, we pretty much go over tickets now, then a few other items then open the floor. 15:03 < mmcgrath> warren: Remind me if I forget at the end. 15:03 < jcollie> not much has happened... someone horked up a bunch of my virtual hosts at work so i've been busy rebuilding them 15:03 < mmcgrath> jcollie: virtual hosts at $DAYJOB or something related to fedora? 15:03 -!- Wakko666 [n=blentz at office.cardomain.com] has joined #fedora-meeting 15:03 < jcollie> $DAYJOB 15:03 -!- wolfy [n=lonewolf at fedora/wolfy] has left #fedora-meeting ["When you breathe, you inspire. When you do not breathe, you expire."] 15:04 < mmcgrath> just checking ;-) 15:04 < mmcgrath> jcollie: k, so nothing new there. We'll move on. 15:04 < mmcgrath> .ticket 398 15:04 < zodbot> mmcgrath: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 15:04 * mmcgrath sees if rmcgrath is around. 15:04 < jcollie> i think that those of us that are interested in working on the streaming should set up a separate meeting to divvy up some tasks 15:05 < mmcgrath> jcollie: not a bad idea. It sounds like you've done most of the work already. Its just a matter of getting that last 10% done (and getting the fas integration for the non streamins stuff) 15:05 < jcollie> yep 15:06 < mmcgrath> alrighty, we'll talk about 398 later if rmcgrath becomes available. 15:06 < mmcgrath> My understanding is that we can do it though. 15:06 < mmcgrath> .tickety 446 15:06 < mmcgrath> .ticket 446 15:06 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 15:06 < mmcgrath> doath 15:06 * dgilmore is here 15:07 < mmcgrath> dgilmore: I think last time we talked about you getting this up on the wiki, any news on that? 15:07 < dgilmore> mmcgrath: i started and got sidetracked 15:07 < mmcgrath> dgilmore: ahh, you're still on it though? 15:07 < dgilmore> mmcgrath: will be done by the end of the weekend 15:07 < dgilmore> yep 15:08 < mmcgrath> AFAIK we just have the one spin so far. 15:08 < mmcgrath> dgilmore: sweet, thanks! 15:08 < mmcgrath> Ok, so thats really the end of it on the tickets side. 15:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- New Wiki 15:08 < mmcgrath> Just a bit of a roundup on the wiki. I've been working on th emigration script and docbook exporter script. 15:08 < mmcgrath> The people listed on http://fedoraproject.org/wiki/Infrastructure/WikiMigration all met yesterday. 15:09 < mmcgrath> I'm going to schedule a few more meetings but a few bumps aside it sounds like we are a GO. 15:09 < mmcgrath> dgilmore: are you on the FESCo ? 15:09 < dgilmore> mmcgrath: i am 15:09 < mmcgrath> dgilmore: at the next meeting would you find a delegate to sign up to be the wiki liason for those sections of the wiki? 15:10 < mmcgrath> unless you want to do it :) 15:10 < dgilmore> mmcgrath: sure 15:10 < mmcgrath> Thanks. 15:10 < dgilmore> mmcgrath: i think jwb volunteered 15:10 * jwb wakes up 15:10 < jwb> huh? 15:10 * dgilmore notes he will largely be away next week 15:10 < mmcgrath> so https://publictest1.fedoraproject.org/wiki/FedoraMain is still up and ready 15:10 < dgilmore> jwb: wiki migration? 15:10 < mmcgrath> dgilmore: ohhh yeah. you're right. he's on there. 15:11 < jwb> dgilmore, mmcgrath: oh, yeah. i put my name there 15:11 < mmcgrath> dgilmore: I'll be away next week as well. 15:11 < mmcgrath> jwb: sorry I missed it there. 15:11 < jwb> i have no idea what that means 15:11 < jwb> do i have to do something? 15:11 < jwb> it just said "contact point" 15:11 < dgilmore> jwb: you get to be whiped 15:11 < mmcgrath> jwb: not yet, we'll be scheduling a meeing again the week after next. In the meantime just go through https://publictest1.fedoraproject.org/wiki/ and look for... doom. 15:11 < dgilmore> jwb: no Just be a point person. 15:12 < jwb> ok great 15:12 < jwb> either way, count me in 15:12 < mmcgrath> cool. 15:12 < mmcgrath> So thats really the latest on the wiki. 15:12 < mmcgrath> Anyone have any questions or concerns? 15:13 < mmcgrath> allrighty, moving on 15:13 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Next week 15:13 < mmcgrath> I'll be gone again next week for training. Its the last traing session I actually have scheduled. 15:13 < mmcgrath> So during the days I'll be unavailable but I'll likely be around most evenings. 15:14 < mmcgrath> Next topic 15:14 < dgilmore> mmcgrath: ill be in Brazil 15:14 * skvidal will be here 15:14 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- nfs1 15:14 < skvidal> people can call/page me 15:14 < skvidal> ugh 15:14 < skvidal> nfs1 15:14 < mmcgrath> NFS1 got built yesterday in a hurry. 15:14 < mmcgrath> while working on xen2 the nfslock issues showed up again then the whole box took a panic. 15:15 < mmcgrath> we'd been serving nfs directly from xen2 so when it goes down the buildsystem goes down. 15:15 < mmcgrath> Anyway, we brought nfs1 up as a RHEL4 box to try to fix the nfs issues, they might have fixed nfs issues but brought on ext3 issues since we're using a 10T ext3 filesystem... 15:15 < mmcgrath> RHEl4 couldn't handle it and started to ioerror. 15:15 < mmcgrath> So I kicked a RHEL5 box and its now nfs1. 15:16 < mmcgrath> Its up, its running. 15:16 < mmcgrath> so far no nfslock issues, if we do get one though we're going to contact steved while its in the bad state and give him a shell to look around. 15:16 < dgilmore> mmcgrath: lets get steved a shell on xen2 and let him monitor nfs1 15:16 < mmcgrath> Really nothing new here except that /mnt/koji is no longer available on xen2, its now on nfs1. 15:17 < mmcgrath> dgilmore: you never know, perhaps magically moving to nfs1 fixed our problem :) 15:17 < mmcgrath> we'll see. 15:17 * skvidal likes magic 15:17 < dgilmore> mmcgrath: we can hope 15:17 < dgilmore> skvidal: voodoo magic is best 15:17 < mmcgrath> heheh 15:17 * skvidal makes a doll of dgilmore 15:17 < mmcgrath> Ok, next item. 15:17 < dgilmore> skvidal: need some hair and fingernails? 15:18 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- s/cvsextras/packagers/ 15:18 < mmcgrath> warren: ping? 15:18 < warren> hi 15:18 < mmcgrath> warren: so we're just going to rename cvsextras to packagers. 15:18 < mmcgrath> which involves 15:18 < warren> So f13 suggested we rename the group after F9 release, at the first scheduled outage. 15:18 < warren> mmcgrath: packager, singular 15:18 < mmcgrath> 1) updating the db. 15:19 < mmcgrath> 2) updating the scripts (and upload script) 15:19 < mmcgrath> 3) updating the documentation 15:19 < mmcgrath> 4) testing? 15:19 < mmcgrath> I really don't think this will be that huge of a deal. 15:19 < mmcgrath> warren: I'll try to get it done sometime the week after F9 ships. Would you mind opening a ticket and bugging me about it that week? 15:19 < warren> mmcgrath: ok 15:20 < warren> mmcgrath: are there any other group names we should rename as well? 15:20 < f13> warren: lets keep the name that will make sense in the future given my newmaintianercontainment proposal 15:20 < warren> as long as we have an outage 15:20 < f13> warren: since I hope to get an intern to work on that this summer 15:20 < warren> f13: is this the one from 2 months ago or so? 15:20 < mmcgrath> warren: yeah we'll schedule an outage. 15:20 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has quit Remote closed the connection 15:20 < f13> warren: http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment 15:21 < mmcgrath> I'm not sure about other group names. 15:21 < warren> Let's ask around 15:21 < warren> there might be other names people want to do 15:21 < warren> f13: ok seems we need to figure out a bigger picture plan then 15:22 < warren> mmcgrath: will get back to you 15:22 < mmcgrath> warren: works for me, lets know well in advance of the outage know because renaming cvsextras I have a pretty good idea of what needs to be done. 15:22 < mmcgrath> but for another group I might not know without more research. 15:22 < mmcgrath> k 15:22 < mmcgrath> warren: when its all ready just create a ticket and bug me. I think we could have it done in an hour or two some night after F9 ships. 15:22 < f13> warren: well, we don't necessarly have to wait to rename 'cvsextras' to /somethihng/ 15:23 < f13> warren: 'fedorapackager' or whatever seems fine, we can pick a name that implies /greater/ rights later 15:23 < warren> f13: I do agree to rename it within the larger plan 15:23 < f13> or less rights. 15:23 < warren> f13: I'm still in favor of numbers instead of group names for that 15:23 < warren> but we're getting off topic 15:23 < mmcgrath> you guys figure that out :) 15:24 < mmcgrath> anyone have any questions about that? We've got plenty of time to discuss it. 15:24 < mmcgrath> if not I'll move on. 15:24 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- app server upgrades. 15:24 < mmcgrath> abadger1999: ping? 15:25 < mmcgrath> I believe toshio wants to upgrade sqlalchemy and python-fedora before the freeze. I think we're on schedule to do that but I'll have to get ahold of him to find out for sure. 15:25 < mmcgrath> which brings me to the next topic 15:25 < abadger1999> here. 15:25 < mmcgrath> oh 15:25 < mmcgrath> there you are :) 15:25 < abadger1999> Today. 15:26 < mmcgrath> abadger1999: want to talk about all of that right quick? 15:26 < abadger1999> Want to do it today/tonight. 15:26 < abadger1999> It would be to both app servers. 15:26 < mmcgrath> abadger1999: "both" ? 15:26 < mmcgrath> which? 15:26 < abadger1999> app4 and app5 15:26 < mmcgrath> app2 is also running tg apps 15:26 < abadger1999> Oh. I was not aware. 15:27 < dgilmore> mmcgrath: i want the new python-fedora 15:27 < abadger1999> then we wantto upgrade that as well. 15:27 < abadger1999> We can issue a new python-fedora for everything if we want. 15:27 < mmcgrath> abadger1999: your call I'm not sure what we'd be comitting to with the new package. 15:27 < abadger1999> Or we can update that when we do the other updates from RHEL, etc. 15:27 < mmcgrath> what are the risks / benefits? 15:27 < mmcgrath> and will this break transifex? 15:28 < abadger1999> All the FAS1 stuff has been removed. Only FAS2 stuff is in it. 15:28 < abadger1999> there's been some rearrangement of modules but the old imports should work with a deprecation warning. 15:28 < mmcgrath> k 15:29 < mmcgrath> sounds pretty low risk, and we can always revert if required. 15:29 < abadger1999> 15:29 < mmcgrath> abadger1999: I'm fine for any time this week on that, if you want me around just ping me or call me. 15:29 < mmcgrath> abadger1999: anything else on that? 15:30 < abadger1999> Nope that's it. 15:30 < mmcgrath> cool. 15:30 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- app5 15:30 < mmcgrath> So yeah, I don't know WTF is going on but app5 is rebooting... a LOT 15:30 < mmcgrath> this comes after the move from x86_64 to i686 15:30 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has joined #fedora-meeting 15:30 < mmcgrath> we're talking between 20-40 times a DAY. 15:30 < mmcgrath> very very strange. 15:30 < mmcgrath> I've got a stack trace, I'm going to try to take it to the virt guys soon. 15:31 < mmcgrath> side note though, aside from that, the i686 move (also done on app2) has proved quite successful memory usage (and therefor swap) is way down. 15:31 < mmcgrath> its been a big win for us. 15:31 < mmcgrath> anyone have any questions / comments? 15:31 -!- viking-ice [n=johannbg at dsl-149-97-225.hive.is] has joined #fedora-meeting 15:31 < mmcgrath> Alrighty, then I'll move on to the last topic of the day before opening the floor. 15:32 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Change Freeze! 15:32 < mmcgrath> This one's for everyone 15:32 < mmcgrath> REMEMBER 15:32 < mmcgrath> DO NOT MAKE ANY CHANGES WITHOUT GETTING APPROVAL ON THE LIST FIRST! 15:32 < mmcgrath> and remember, you'll be asked the question "Why can't this wait until after F9 gets released" 15:33 < mmcgrath> I'll be gone much of next week which makes the freeze perfect. 15:33 < warren> under pain of 15:33 * mmcgrath looks up exact date again 15:33 < mmcgrath> warren: under pain of CURSE! 15:33 < skvidal> under pain of pain 15:33 < warren> I can advise against pain. 15:34 < mmcgrath> There we go, so the freeze starts the 15th. The release is on the 29th. The freeze is lifted on the 30th. 15:34 < yingbull> pain's scary. 15:34 < mmcgrath> Obvious exceptions include outages and things already scheduled for the release (mm type stuff, the website, etc) 15:34 < mmcgrath> other then that. you must get approval on the list before making changes. If you're working on tickets and people get cranky, just let them know we're under a freeze. 15:34 < skvidal> mmcgrath: it's okay to bring up new boxes unrelated to the release? 15:34 < ivazquez> Should we hold it until the Monday following? 15:35 < skvidal> mmcgrath: ie: if I get all the statics, etc from BU 15:35 < mmcgrath> skvidal: take it to the list! But yeah, that shouldn't be a problem. 15:35 < skvidal> mmcgrath: will do 15:35 < mmcgrath> ivazquez: I thought about that, in the past though, for the most part, things settled down from the release the day after. 15:36 < ivazquez> Okay. 15:36 < mmcgrath> anyone have any questions / comments about that? 15:36 < mmcgrath> alrighty, then we'll open the floor 15:36 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 15:36 * dgilmore has nothing right now 15:36 < mmcgrath> Anyone have anything they'd like to discuss? A release is coming, lots of stuff has been going on. 15:37 < notting> how are we ensuring the ability to get the bits to our tier0 mirrors? 15:37 < mmcgrath> notting: same as we had been, AFAIK our mirror system (and I2) is functional again. 15:37 < notting> that's not what mdomsch's mail implied 15:37 < mmcgrath> notting: which email and when? 15:38 < notting> to mirror-list 15:38 < dgilmore> notting: no, it implied a work around was setup 15:38 < dgilmore> mmcgrath: a couple of hours ago 15:38 < dgilmore> mmcgrath: 2 boxes were setup for Tier 0 I2 masters 15:39 < mmcgrath> that was my understanding. We don't have the permanent solution in place but a working one. 15:39 < mmcgrath> we'll probably want to make sure the working one stays as is until after the 30th. 15:39 < dgilmore> mmcgrath: they have static I2 routes to dl.fedora.redhat.com boxes 15:39 < mmcgrath> notting: I'll follow up with mdomsch to make sure whats going on there. 15:39 < mmcgrath> .any mdomsch 15:39 < zodbot> mmcgrath: mdomsch was last seen in #fedora-meeting 1 hour, 9 minutes, and 24 seconds ago: *** mdomsch has quit IRC (Remote closed the connection) 15:39 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has quit Remote closed the connection 15:40 < mmcgrath> Alrighty, anyone have anything else to discuss? 15:40 < dgilmore> nope 15:40 < mmcgrath> k, we'll close the meeting in 30 15:41 < mmcgrath> 15 15:41 < mmcgrath> 5 15:41 < notting> dgilmore: so, the static route & download1 are bandwidth-unclogged enough to sync OK? 15:41 < dgilmore> Thanks mmcgrath :) 15:41 < notting> dgilmore: with no one using it, are we sure that download1 is synced? :) 15:41 < dgilmore> notting: i believe so. 15:42 < mmcgrath> notting: we'll have to talk to them to find out for sure. 15:42 * mmcgrath just sent an email to mdomsch to verify. 15:42 < notting> maybe i'm paranoid 15:42 < mmcgrath> notting: you're once bitten. 15:42 < mmcgrath> nothing wrong with that. The fact is the whole I2 connection thing showed a major problem we have. and the fact that galgoci is the _only_ person at Red hat with access and no how to fix it is much less comforting. 15:43 < dgilmore> notting: i believe download1 is down 15:43 < mmcgrath> even his backup told us that he was really the only guy we'd want doing that. 15:44 -!- k0k [n=k0k at fedora/k0k] has quit Connection timed out 15:44 < mmcgrath> notting: we'll just have to wait and see if what we think mdomsch said is actually the way things are. That mirror has been down since before Feb 20th so its hard to say the state of things (considering they only just recently got back up and running) 15:44 < mmcgrath> Anywho, not much we can do but check with the mirrors list and mdomsch and make sure everyone's happy with where things are for the release. 15:44 < mmcgrath> Anyone have anything else? If not we'll close the meeting in 30 15:45 -!- Milanito [n=Matt at 32.12.70-86.rev.gaoland.net] has joined #fedora-meeting 15:45 < mmcgrath> 10 15:45 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ricky at fedoraproject.org Thu Apr 10 23:24:24 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 10 Apr 2008 19:24:24 -0400 Subject: Fedora CA Project In-Reply-To: <200804101517.28389.dennis@ausil.us> References: <200803251804.21899.dennis@ausil.us> <200804101517.28389.dennis@ausil.us> Message-ID: <20080410232424.GC11733@Max> On 2008-04-10 03:17:23 PM, Dennis Gilmore wrote: > To follow up on this. Im going to be looking at dogtag first. Ive had a > promise from them to help us when we have issues. > > OpenCA seems to have stalled development wise. > > ejbca has a very heavy footprint. > > something Custom i think is too big of a task. > > So people wanting to help with setting up, implementing and testing please > raise your hands now. Whichever we end up going with, I'd love to help out too (testing, FAS2/webapp integration, etc.). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Sat Apr 12 04:14:10 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 11 Apr 2008 21:14:10 -0700 Subject: app servers updated Message-ID: <48003712.5020707@gmail.com> I've built and added to the fedora-infrastructure repo the following packages: * fas-clients -- Contains a backported patch so we don't see deprecation warnings when run with the new python-fedora. * fas -- Contains one backported patch that we're currently running on fas1 and fas2. * python-sqlalchemy -- Major version upgrade. from 0.3 => 0.4. AFAIK this update only affects smolt and packagedb, both of which have been ported and tested with this release. * fedora-packagedb -- Major changes to support SQLAlchemy 0.4 and to re-optimize some code paths for FAS2. This release should be much faster for certain operations like viewing the firefox page or mass branching. * python-fedora -- Major changes. removed all FAS1 code. Moved BaseClient and deprecated the old location. Updated json.py for SQLAlchemy-0.4. Added a kludge for bz_email handling. Threaded jsonfasvisit so it contacts the fas server less often. fas-clients, python-sqlalchemy, fedora-packagedb, and python-fedora have been installed on app2, app4, and app5.vpn. These are our TurboGears app servers. I haven't installed them on fas1 & fas2 or any of the other machines yet. We can do that if we want or wait until after the change freeze. *If there's any problems with the new packagedb or other TurboGears apps please contact me so I can look at fixing it or rolling back these changes before the change freeze. (abadger1999 on freenode)* The next version of python-fedora will likely have some incompatible changes to the interface between BaseClient and the Server. Those changes will make error handling between the Server and Clients better and standardize some of the things that we currently do in an ad hoc fashion but will require modifications of all the servers that talk to clients in order to work. I'll let people know when I have a new version of BaseClient ready to test against. The specification from the server side view is here:: http://bzr.fedorahosted.org/bzr/python-fedora-python-fedora-devel?cmd=content;path=doc/service.rst -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Matt_Domsch at Dell.com Sat Apr 12 15:01:59 2008 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Sat, 12 Apr 2008 10:01:59 -0500 Subject: need ordb.org removed from Red Hat MX mail servers Message-ID: Bounces are getting this message: < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.> Whomever is responsible for Red Hat's mail servers needs to make this change. Thanks, Matt -----Original Message----- From: Domsch, Matt Sent: Mon 4/7/2008 9:44 AM To: soc-request at redhat.com; fedora-infrastructure-list at redhat.com; mirror-admin at fedoraproject.org; ftp+fedora at redhat.com; rel-eng at fedoraproject.org Subject: download*.fedora.redhat.com rsyncd change request Your message did not reach some or all of the intended recipients. Subject: download*.fedora.redhat.com rsyncd change request Sent: 4/7/2008?9:44 AM The following recipient(s) could not be reached: ??hugo at devin.com.br?on?4/12/2008?9:50 AM ??Could not deliver the message in the time limit specified. Please retry or contact your administrator. ??< mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.> From mmcgrath at redhat.com Sat Apr 12 22:12:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 12 Apr 2008 17:12:51 -0500 (CDT) Subject: need ordb.org removed from Red Hat MX mail servers In-Reply-To: References: Message-ID: I've created a ticket. -Mike On Sat, 12 Apr 2008, Matt_Domsch at Dell.com wrote: > Bounces are getting this message: > > < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.> > > Whomever is responsible for Red Hat's mail servers needs to make this change. > > Thanks, > Matt > > -----Original Message----- > From: Domsch, Matt > Sent: Mon 4/7/2008 9:44 AM > To: soc-request at redhat.com; fedora-infrastructure-list at redhat.com; mirror-admin at fedoraproject.org; ftp+fedora at redhat.com; rel-eng at fedoraproject.org > Subject: download*.fedora.redhat.com rsyncd change request > > > Your message did not reach some or all of the intended recipients. > > Subject: download*.fedora.redhat.com rsyncd change request > Sent: 4/7/2008?9:44 AM > > The following recipient(s) could not be reached: > > ??hugo at devin.com.br?on?4/12/2008?9:50 AM > ??Could not deliver the message in the time limit specified. Please retry or contact your administrator. > ??< mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.> > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From german.g.ramirez at gmail.com Sat Apr 12 22:13:57 2008 From: german.g.ramirez at gmail.com (German G. Ramirez) Date: Sun, 13 Apr 2008 01:13:57 +0300 Subject: Introduction Message-ID: <7d417e0804121513l198c6c89k30ab0904209a1dc4@mail.gmail.com> Dear fedora-infrastructure-list, Permit me to introduce myself.My name is German I'm a 26 y.o Mexican living in Kiev,Ukraine.I own a bachelor degree in computer science and have had work experience as system administrator and programming.I'm currently running fedora 8 on my laptop.I do not have experience using Python but I'm willing to learn it.Since fedora is my new hobby I would like to contribute to the fedora project and work with people sharing the same interests just for the fun of doing it. Looking forward to work with you all. Regards, German From Matt_Domsch at dell.com Sun Apr 13 04:06:24 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 12 Apr 2008 23:06:24 -0500 Subject: proposed MM patch: improve rsync_acl query Message-ID: <20080413040624.GA32506@auslistsprd01.us.dell.com> mirrormanager has a query that lets the mirrors, and eventually, the master mirrors, get the Access Control List directly from the database. The current query is poor in several ways: it's very slow as it uses python object walks, which results in hundreds of database hits instead of only one. It doesn't let the user specify they want to limit by hosts on Internet2, or only public hosts. Patch below fixes these. The URL will work as: http://admin.fedoraproject.org/mirrormanager/rsync_acl?internet2_only=1&public_only=1 The arguments on the end are optional. The mirrors are starting to use this query to populate their own rsync ACLs. It's not critical that it go in before F9 launch, but I think it's quite low-risk. I've tested it locally and it works as expected. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From a.badger at gmail.com Sun Apr 13 18:35:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 13 Apr 2008 11:35:55 -0700 Subject: proposed MM patch: improve rsync_acl query In-Reply-To: <20080413040624.GA32506@auslistsprd01.us.dell.com> References: <20080413040624.GA32506@auslistsprd01.us.dell.com> Message-ID: <4802528B.8050503@gmail.com> Matt Domsch wrote: > mirrormanager has a query that lets the mirrors, and eventually, the > master mirrors, get the Access Control List directly from the > database. The current query is poor in several ways: it's very slow > as it uses python object walks, which results in hundreds of database > hits instead of only one. It doesn't let the user specify they want > to limit by hosts on Internet2, or only public hosts. > > Patch below fixes these. The URL will work as: > > http://admin.fedoraproject.org/mirrormanager/rsync_acl?internet2_only=1&public_only=1 > > The arguments on the end are optional. > > The mirrors are starting to use this query to populate their own rsync > ACLs. It's not critical that it go in before F9 launch, but I think > it's quite low-risk. I've tested it locally and it works as expected. > Err... no patch was attached but the feature sounds good. If it's really low risk it sounds like a win to put it in. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Matt_Domsch at dell.com Sun Apr 13 19:09:08 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 13 Apr 2008 14:09:08 -0500 Subject: proposed MM patch: improve rsync_acl query In-Reply-To: <4802528B.8050503@gmail.com> References: <20080413040624.GA32506@auslistsprd01.us.dell.com> <4802528B.8050503@gmail.com> Message-ID: <20080413190908.GA11305@auslistsprd01.us.dell.com> On Sun, Apr 13, 2008 at 11:35:55AM -0700, Toshio Kuratomi wrote: > Matt Domsch wrote: > >mirrormanager has a query that lets the mirrors, and eventually, the > >master mirrors, get the Access Control List directly from the > >database. The current query is poor in several ways: it's very slow > >as it uses python object walks, which results in hundreds of database > >hits instead of only one. It doesn't let the user specify they want > >to limit by hosts on Internet2, or only public hosts. > > > >Patch below fixes these. The URL will work as: > > > >http://admin.fedoraproject.org/mirrormanager/rsync_acl?internet2_only=1&public_only=1 > > > >The arguments on the end are optional. > > > >The mirrors are starting to use this query to populate their own rsync > >ACLs. It's not critical that it go in before F9 launch, but I think > >it's quite low-risk. I've tested it locally and it works as expected. > > > Err... no patch was attached but the feature sounds good. If it's > really low risk it sounds like a win to put it in. Doh. mailman ate the patch. Here I committed it to the upstream, but I haven't yet pushed to puppet. Here's the patch. http://git.fedorahosted.org/git/mirrormanager?p=mirrormanager;a=commitdiff;h=ed07dba2ba35c3be22eb713138a98cc2d20f7851 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Sun Apr 13 21:11:39 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 13 Apr 2008 16:11:39 -0500 Subject: snapmirror status tool? Message-ID: <20080413211139.GA17489@auslistsprd01.us.dell.com> One of the challenges to set up push-mirroring (where a tool somehow informs mirrors that there's new content ready to be pulled) is that we're using NetApps with snapmirroring to sync data across PHX, TPA, and RDU. While we know when rel-eng uploads data to the netapp in PHX, we don't know when all that data is quite synced to the netapps in TPA and RDU. Or do we? http://ecserv1.uwaterloo.ca/netapp/man/man1/na_snapmirror.1.html notes that there is a command, snapmirror status, which can be used on the filers to determine mirroring status/progress/complete-or-not, to each destination. I can't run this command on the filers, but with the help of SOC, we should be able to have an automated tool that runs this command on our behalf regularly and posts the results somewhere that we can read the status... If we know the status, then we can implement push-mirroring to the various mirror tiers. Tell tier 0 mirrors when the content is done snapmirroring and ready for them to pull. Then tell the tier 1 mirrors when the Tier 0 mirrors are done. etc. Mike, can you file a request with SOC requesting such a tool? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Sun Apr 13 22:56:07 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 13 Apr 2008 17:56:07 -0500 (CDT) Subject: snapmirror status tool? In-Reply-To: <20080413211139.GA17489@auslistsprd01.us.dell.com> References: <20080413211139.GA17489@auslistsprd01.us.dell.com> Message-ID: On Sun, 13 Apr 2008, Matt Domsch wrote: > One of the challenges to set up push-mirroring (where a tool somehow > informs mirrors that there's new content ready to be pulled) is that > we're using NetApps with snapmirroring to sync data across PHX, TPA, > and RDU. While we know when rel-eng uploads data to the netapp in > PHX, we don't know when all that data is quite synced to the netapps > in TPA and RDU. > > Or do we? > > http://ecserv1.uwaterloo.ca/netapp/man/man1/na_snapmirror.1.html > > notes that there is a command, snapmirror status, which can be used on > the filers to determine mirroring status/progress/complete-or-not, to > each destination. I can't run this command on the filers, but with > the help of SOC, we should be able to have an automated tool that runs > this command on our behalf regularly and posts the results somewhere > that we can read the status... > > If we know the status, then we can implement push-mirroring to the > various mirror tiers. Tell tier 0 mirrors when the content is done > snapmirroring and ready for them to pull. Then tell the tier 1 > mirrors when the Tier 0 mirrors are done. etc. > > Mike, can you file a request with SOC requesting such a tool? > yeah, I'll drop a line. I requested access to the machines themselves so we could look but it got denied. -Mike From sbathe at redhat.com Mon Apr 14 07:28:26 2008 From: sbathe at redhat.com (Saurabh Bathe) Date: Mon, 14 Apr 2008 12:58:26 +0530 Subject: need ordb.org removed from Red Hat MX mail servers In-Reply-To: References: Message-ID: <4803079A.7030603@redhat.com> Matt_Domsch at Dell.com wrote: > Bounces are getting this message: > > < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on December 18, 2006. Please remove from your mailserver.> > > Whomever is responsible for Red Hat's mail servers needs to make this change. Red Hat servers do not use ordb.org. The messages are bouncing from mail.devin.com.br, while delivering mails to hugo at devin.com.br. -- Thanks, Saurabh Bathe Senior Systems Administrator Red Hat, Inc From Matt_Domsch at dell.com Mon Apr 14 15:00:20 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 14 Apr 2008 10:00:20 -0500 Subject: proposed MM patch: improve rsync_acl query In-Reply-To: <20080413190908.GA11305@auslistsprd01.us.dell.com> References: <20080413040624.GA32506@auslistsprd01.us.dell.com> <4802528B.8050503@gmail.com> <20080413190908.GA11305@auslistsprd01.us.dell.com> Message-ID: <20080414150020.GB31475@auslistsprd01.us.dell.com> On Sun, Apr 13, 2008 at 02:09:08PM -0500, Matt Domsch wrote: > On Sun, Apr 13, 2008 at 11:35:55AM -0700, Toshio Kuratomi wrote: > > Matt Domsch wrote: > > >mirrormanager has a query that lets the mirrors, and eventually, the > > >master mirrors, get the Access Control List directly from the > > >database. The current query is poor in several ways: it's very slow > > >as it uses python object walks, which results in hundreds of database > > >hits instead of only one. It doesn't let the user specify they want > > >to limit by hosts on Internet2, or only public hosts. > > > > > >Patch below fixes these. The URL will work as: > > > > > >http://admin.fedoraproject.org/mirrormanager/rsync_acl?internet2_only=1&public_only=1 > > > > > >The arguments on the end are optional. > > > > > >The mirrors are starting to use this query to populate their own rsync > > >ACLs. It's not critical that it go in before F9 launch, but I think > > >it's quite low-risk. I've tested it locally and it works as expected. > > > > > Err... no patch was attached but the feature sounds good. If it's > > really low risk it sounds like a win to put it in. > > Doh. mailman ate the patch. Here I committed it to the upstream, but > I haven't yet pushed to puppet. Here's the patch. > > http://git.fedorahosted.org/git/mirrormanager?p=mirrormanager;a=commitdiff;h=ed07dba2ba35c3be22eb713138a98cc2d20f7851 With no objections and two acks, I went ahead and put this in production. Query time down from 60s to 1s. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Christian.Iseli at unil.ch Mon Apr 14 15:08:41 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Mon, 14 Apr 2008 17:08:41 +0200 Subject: CVS common directory Message-ID: <20080414170841.5bc9a9f5@ludwig-alpha.unil.ch> Dear infra people, Just a puzzling question here. I have a complete CVS checkout of the RPMS (since a fairly long time: $ cat CVS/Root :ext:c4chris at cvs.fedora.redhat.com:/cvs/extras ) The puzzling thing is that 141 of the 5977 packages with a devel directory have a common subdirectory in there. I.e.,: $ ls -d */devel|wc -l 5977 $ ls -d */devel/common|wc -l 141 And the question is: why ? Is it just me, or is there some strangeness in the CVS repo ? Cheers, Christian From jima at beer.tclug.org Mon Apr 14 18:15:17 2008 From: jima at beer.tclug.org (Jima) Date: Mon, 14 Apr 2008 13:15:17 -0500 (CDT) Subject: proposed MM patch: improve rsync_acl query In-Reply-To: <20080414150020.GB31475@auslistsprd01.us.dell.com> References: <20080413040624.GA32506@auslistsprd01.us.dell.com> <4802528B.8050503@gmail.com> <20080413190908.GA11305@auslistsprd01.us.dell.com> <20080414150020.GB31475@auslistsprd01.us.dell.com> Message-ID: On Mon, 14 Apr 2008, Matt Domsch wrote: > With no objections and two acks, I went ahead and put this in > production. Query time down from 60s to 1s. Awesome, nice work. Jima From ivazqueznet at gmail.com Mon Apr 14 18:39:48 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 14 Apr 2008 14:39:48 -0400 Subject: CVS common directory In-Reply-To: <20080414170841.5bc9a9f5@ludwig-alpha.unil.ch> References: <20080414170841.5bc9a9f5@ludwig-alpha.unil.ch> Message-ID: <1208198388.586.13.camel@ignacio.lan> On Mon, 2008-04-14 at 17:08 +0200, Christian Iseli wrote: > And the question is: why ? Is it just me, or is there some strangeness > in the CVS repo ? The Makefile inherited from Extras(?) pulls down common if it can't be found in .. or ../.. . So if for some reason you have it in ../../.. (like I do), you automagically gain another copy. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Apr 14 23:03:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 14 Apr 2008 16:03:55 -0700 Subject: Jury Duty Message-ID: <4803E2DB.2050102@gmail.com> I've got a jury summons for tomorrow. I don't know if there will be a chance for me to be online or working while I'm there although the library across the street has free wireless. So I should be able to sneak online at lunch, at least. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Tue Apr 15 00:41:33 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 14 Apr 2008 19:41:33 -0500 (CDT) Subject: [redhat.com #609992] need ordb.org removed from Red Hat MX mail servers (fwd) Message-ID: >From the soc (Marek!) Hello Mike, On Sat Apr 12 18:13:14 2008, mmcgrath at redhat.com wrote: > Do you guys know anything about this? We are not using this RBL. That message has been bounced from mail.devin.com.br, while delivered the mail to hugo at devin.com.br. Regards, > -Mike > > ---------- Forwarded message ---------- > Date: Sat, 12 Apr 2008 10:01:59 -0500 > From: Matt_Domsch at Dell.com > Reply-To: fedora-infrastructure-list at redhat.com > To: fedora-infrastructure-list at redhat.com > Subject: need ordb.org removed from Red Hat MX mail servers > > Bounces are getting this message: > > < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on > December 18, 2006. Please remove from your mailserver.> > > Whomever is responsible for Red Hat's mail servers needs to make this > change. > > Thanks, > Matt > > > Your message did not reach some or all of the intended recipients. > > Subject: download*.fedora.redhat.com rsyncd change request > Sent: 4/7/2008 9:44 AM > > The following recipient(s) could not be reached: > > hugo at devin.com.br on 4/12/2008 9:50 AM > Could not deliver the message in the time limit specified. Please > retry or contact your administrator. > < mx1.util.phx.redhat.com #4.4.7 SMTP; 451 ordb.org was shut down on > December 18, 2006. Please remove from your mailserver.> > > > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list From Christian.Iseli at unil.ch Tue Apr 15 07:43:26 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Tue, 15 Apr 2008 09:43:26 +0200 Subject: CVS common directory In-Reply-To: <1208198388.586.13.camel@ignacio.lan> References: <20080414170841.5bc9a9f5@ludwig-alpha.unil.ch> <1208198388.586.13.camel@ignacio.lan> Message-ID: <20080415094326.4dc092da@ludwig-alpha.unil.ch> On Mon, 14 Apr 2008 14:39:48 -0400, Ignacio Vazquez-Abrams wrote: > The Makefile inherited from Extras(?) pulls down common if it can't be > found in .. or ../.. . So if for some reason you have it in ../../.. > (like I do), you automagically gain another copy. Right, that must have been something like that. I have removed them and they haven't returned with a new update. I suppose I must have made something with make inside those directories at some point, and gained the common and not noticed... Thanks Ignacio. Cheers, Christian From mmcgrath at redhat.com Tue Apr 15 12:12:43 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 15 Apr 2008 07:12:43 -0500 (CDT) Subject: Change Freeze!! Message-ID: Beware the ides of April! Today is important for more then just US taxpayers! Its change freeze time! Sit back, relax and don't change anything! If you have to change something (non emergency) come here first and get permission. Explain why this change is important enough that it can't wait until after F9 ships. Anyone in sysadmin-main can give permission but you can't give permission to yourself. -Mike From mmcgrath at redhat.com Tue Apr 15 13:38:55 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 15 Apr 2008 08:38:55 -0500 (CDT) Subject: Change (already) - steved Message-ID: One thing we'd been talking about before the freeze but just didn't get around to was giving steved (nfs expert) access to our nfs box where /mnt/koji lives as we still seem to be having nfslock issues (though they are less frequent now). This is mostly so A) he can see how things are setup before an outage and B) get immediate access to see what happened during the outage. I'd like to get his account on there (and possibly xen2 if he needs it) before the freeze so we can keep the outage time to a minimum and possibly have a fix right then or at least have a fix after the change freeze ready. Anyone opposed? The only change here is actually giving steved access to the boxes (with sudo) any other changes will have to come back through the list when we have them. -Mike PS. This isn't in an SOP but if nfslock happens on nfs1 and steved isn't around. Anyone in sysadmin-main can just reboot the box which will cause a quick down time but we've yet to figure out how to bring nfslock back up sanely without the reboot. From jkeating at redhat.com Tue Apr 15 13:51:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Apr 2008 09:51:07 -0400 Subject: Change (already) - steved In-Reply-To: References: Message-ID: <1208267467.3185.98.camel@localhost.localdomain> On Tue, 2008-04-15 at 08:38 -0500, Mike McGrath wrote: > > I'd like to get his account on there (and possibly xen2 if he needs it) > before the freeze so we can keep the outage time to a minimum and possibly > have a fix right then or at least have a fix after the change freeze > ready. > > Anyone opposed? The only change here is actually giving steved access to > the boxes (with sudo) any other changes will have to come back through the > list when we have them. This change has a +1 from me. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Tue Apr 15 14:50:35 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Apr 2008 07:50:35 -0700 Subject: Change (already) - steved In-Reply-To: References: Message-ID: <4804C0BB.2040806@gmail.com> Mike McGrath wrote: > One thing we'd been talking about before the freeze but just didn't get > around to was giving steved (nfs expert) access to our nfs box where > /mnt/koji lives as we still seem to be having nfslock issues (though they > are less frequent now). > > This is mostly so A) he can see how things are setup before an outage and > B) get immediate access to see what happened during the outage. > > I'd like to get his account on there (and possibly xen2 if he needs it) > before the freeze so we can keep the outage time to a minimum and possibly > have a fix right then or at least have a fix after the change freeze > ready. > > Anyone opposed? The only change here is actually giving steved access to > the boxes (with sudo) any other changes will have to come back through the > list when we have them. > > -Mike > > > PS. This isn't in an SOP but if nfslock happens on nfs1 and steved isn't > around. Anyone in sysadmin-main can just reboot the box which will cause > a quick down time but we've yet to figure out how to bring nfslock back up > sanely without the reboot. > +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lmacken at redhat.com Tue Apr 15 15:36:58 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 15 Apr 2008 11:36:58 -0400 Subject: Change (already) - steved In-Reply-To: References: Message-ID: <20080415153658.GE3108@crow.boston.redhat.com> On Tue, Apr 15, 2008 at 08:38:55AM -0500, Mike McGrath wrote: > One thing we'd been talking about before the freeze but just didn't get > around to was giving steved (nfs expert) access to our nfs box where > /mnt/koji lives as we still seem to be having nfslock issues (though they > are less frequent now). > > This is mostly so A) he can see how things are setup before an outage and > B) get immediate access to see what happened during the outage. > > I'd like to get his account on there (and possibly xen2 if he needs it) > before the freeze so we can keep the outage time to a minimum and possibly > have a fix right then or at least have a fix after the change freeze > ready. > > Anyone opposed? The only change here is actually giving steved access to > the boxes (with sudo) any other changes will have to come back through the > list when we have them. > > -Mike > > > PS. This isn't in an SOP but if nfslock happens on nfs1 and steved isn't > around. Anyone in sysadmin-main can just reboot the box which will cause > a quick down time but we've yet to figure out how to bring nfslock back up > sanely without the reboot. +1 luke From rordway at oregonstate.edu Tue Apr 15 17:37:44 2008 From: rordway at oregonstate.edu (Ryan Ordway) Date: Tue, 15 Apr 2008 10:37:44 -0700 Subject: Change (already) - steved In-Reply-To: References: Message-ID: <5FC2F3BB-8AE3-4889-9D75-8D6C6DD05E5D@oregonstate.edu> On Apr 15, 2008, at 6:38 AM, Mike McGrath wrote: > > Anyone opposed? The only change here is actually giving steved > access to > the boxes (with sudo) any other changes will have to come back > through the > list when we have them. +1 -- Ryan Ordway E-mail: rordway at oregonstate.edu Unix Systems Administrator rordway at library.oregonstate.edu OSU Libraries, Corvallis, OR 97331 Office: Valley Library #4657 From a.badger at gmail.com Tue Apr 15 19:23:05 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Apr 2008 12:23:05 -0700 Subject: Change freeze request: Fix invalid login pages Message-ID: <48050099.2020809@gmail.com> When I built the last python-fedora, I built the package in my working tree instead of making a fresh branch. This means the python-fedora package I deployed on Friday has some incompatible changes that weren't meant to go in until the next release. This is leading people to get an internal server error when they try to login with an invalid username/password. There's two options: spin a new package based off the actual python-fedora-0.2.99.8. The diff for that would look like bzr-0.2.99.8-current.patch. The alternative is to only fix the problem that we know we're having with BaseClient. The patch for that is quite a bit smaller: it's just a few lines to change exception handling in fas2.py and jsonfasprovider.py to use the new exception hierarchy in BaseClient. Risk for option #1: we have had the new python-fedora deployed since Friday and this is the only problem reported so far. The patch is bigger than for option #2 and thus there's more room for unexpected problems. Risk for option #2: We definitely do not want to push this package out to the other servers as it's likely to break error handling in clients because of the new exception hierarchy. Since we're in change freeze we're not likely to do that for a while. I'm inclined for option #2. What do others think? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: bzr-0.2.99.8-current.patch Type: text/x-patch Size: 5079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Wed Apr 16 01:04:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 15 Apr 2008 20:04:23 -0500 (CDT) Subject: Change freeze request: Fix invalid login pages In-Reply-To: <48050099.2020809@gmail.com> References: <48050099.2020809@gmail.com> Message-ID: On Tue, 15 Apr 2008, Toshio Kuratomi wrote: > There's two options: spin a new package based off the actual > python-fedora-0.2.99.8. The diff for that would look like > bzr-0.2.99.8-current.patch. > > The alternative is to only fix the problem that we know we're having with > BaseClient. The patch for that is quite a bit smaller: it's just a few lines > to change exception handling in fas2.py and jsonfasprovider.py to use the new > exception hierarchy in BaseClient. > > Risk for option #1: we have had the new python-fedora deployed since Friday > and this is the only problem reported so far. The patch is bigger than for > option #2 and thus there's more room for unexpected problems. > > Risk for option #2: We definitely do not want to push this package out to the > other servers as it's likely to break error handling in clients because of the > new exception hierarchy. Since we're in change freeze we're not likely to do > that for a while. > > I'm inclined for option #2. What do others think? > +1 to #2 -Mike From mmcgrath at redhat.com Wed Apr 16 01:24:11 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 15 Apr 2008 20:24:11 -0500 (CDT) Subject: Emergency Change (app4) Message-ID: Well our change freeze isn't off to a great start. But we'll get there. app4 was in a bit of trouble tonight and we got some alerts from slow to respond apps. Since the xen host had it available I doubled the RAM on app4 to help it. This seemed to be the lowest risk change and to revert should be fairly simple. -Mike From lmacken at redhat.com Wed Apr 16 03:00:30 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 15 Apr 2008 23:00:30 -0400 Subject: Change freeze request: Fix invalid login pages In-Reply-To: <48050099.2020809@gmail.com> References: <48050099.2020809@gmail.com> Message-ID: <20080416030029.GF3108@crow.boston.redhat.com> On Tue, Apr 15, 2008 at 12:23:05PM -0700, Toshio Kuratomi wrote: > When I built the last python-fedora, I built the package in my working tree > instead of making a fresh branch. This means the python-fedora package I > deployed on Friday has some incompatible changes that weren't meant to go > in until the next release. This is leading people to get an internal > server error when they try to login with an invalid username/password. > > There's two options: spin a new package based off the actual > python-fedora-0.2.99.8. The diff for that would look like > bzr-0.2.99.8-current.patch. > > The alternative is to only fix the problem that we know we're having with > BaseClient. The patch for that is quite a bit smaller: it's just a few > lines to change exception handling in fas2.py and jsonfasprovider.py to use > the new exception hierarchy in BaseClient. > > Risk for option #1: we have had the new python-fedora deployed since Friday > and this is the only problem reported so far. The patch is bigger than for > option #2 and thus there's more room for unexpected problems. > > Risk for option #2: We definitely do not want to push this package out to > the other servers as it's likely to break error handling in clients because > of the new exception hierarchy. Since we're in change freeze we're not > likely to do that for a while. > > I'm inclined for option #2. What do others think? Option #2 sounds like good idea to me. luke From michael.yingbull at gmail.com Wed Apr 16 03:49:47 2008 From: michael.yingbull at gmail.com (Michael Yingbull) Date: Tue, 15 Apr 2008 21:49:47 -0600 Subject: Change freeze request: Fix invalid login pages In-Reply-To: <48050099.2020809@gmail.com> References: <48050099.2020809@gmail.com> Message-ID: <8c0317740804152049y4c2b60b6ybb0f7644d30b8e54@mail.gmail.com> I'd go with #2. 2008/4/15 Toshio Kuratomi : > When I built the last python-fedora, I built the package in my working > tree instead of making a fresh branch. This means the python-fedora package > I deployed on Friday has some incompatible changes that weren't meant to go > in until the next release. This is leading people to get an internal server > error when they try to login with an invalid username/password. > > There's two options: spin a new package based off the actual > python-fedora-0.2.99.8. The diff for that would look like > bzr-0.2.99.8-current.patch. > > The alternative is to only fix the problem that we know we're having with > BaseClient. The patch for that is quite a bit smaller: it's just a few > lines to change exception handling in fas2.py and jsonfasprovider.py to use > the new exception hierarchy in BaseClient. > > Risk for option #1: we have had the new python-fedora deployed since > Friday and this is the only problem reported so far. The patch is bigger > than for option #2 and thus there's more room for unexpected problems. > > Risk for option #2: We definitely do not want to push this package out to > the other servers as it's likely to break error handling in clients because > of the new exception hierarchy. Since we're in change freeze we're not > likely to do that for a while. > > I'm inclined for option #2. What do others think? > > -Toshio > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diegobz at gmail.com Wed Apr 16 12:50:28 2008 From: diegobz at gmail.com (=?ISO-8859-1?Q?Diego_B=FArigo_Zacar=E3o?=) Date: Wed, 16 Apr 2008 09:50:28 -0300 Subject: =?iso-8859-1?q?Self-Introduction=3A_Diego_B=FArigo_Zacar=E3o?= Message-ID: <6600c1b10804160550j76873af9qca8533ffa5917205@mail.gmail.com> Hello, all! I have been contributing with Fedora Project for years, mainly as Ambassador and Translator. Now, I'm running around the web development. Currently I'm working on some Transifex enhancements and that drives me to be the newest member of Fedora Infrastructure Projetc. I'm glad to be here! ;) Thanks -- Diego B?rigo Zacar?o Linux User #402589 USE SOFTWARE LIVRE -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricky at fedoraproject.org Wed Apr 16 20:07:56 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 16 Apr 2008 16:07:56 -0400 Subject: Change freeze request: Enforce website freeze in syncStatic.sh Message-ID: <20080416200756.GA29076@Max> I'd like to update syncStatic.sh to enforce the website change freeze (in case I accidentally run make push). Here is the patch for the change: Index: syncStatic.sh =================================================================== RCS file: /cvs/puppet/configs/system/syncStatic.sh,v retrieving revision 1.20 diff -u -r1.20 syncStatic.sh --- syncStatic.sh 12 Dec 2007 23:11:07 -0000 1.20 +++ syncStatic.sh 16 Apr 2008 20:06:34 -0000 @@ -22,7 +22,8 @@ cd $TEMP /usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > /dev/null 2>&1 cd fedora-web -/usr/bin/git checkout origin/live > /dev/null 2>&1 +# Checkout last F8 commit +/usr/bin/git checkout 091d53ea83b78e7a5ea2933be9100e74359802ee > /dev/null 2>&1 cd fedoraproject.org /bin/rm -rf /var/lib/puppet/application/fedoraproject.org/* What do you think? Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikem at redhat.com Wed Apr 16 22:15:42 2008 From: mikem at redhat.com (Mike McLean) Date: Wed, 16 Apr 2008 18:15:42 -0400 Subject: cacti misreports koji disk space Message-ID: <48067A8E.7030802@redhat.com> For a while I would look at the /mnt/koji space graph in Cacti and say to myself "boy, garbage collection sure has managed to slow the growth in space usage." The graph was really leveling off. https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=280 But then I realized: it's too level. If you get the csv data from Cacti, the numbers for the last few months are identical. The data shows 2.1990232545e+12 used, which is suspiciously close to exactly 2T (and wrong, df reports 2.7T). The free space is stuck at the same number. Oddly the total space is reported as 4.3980465091e+12, which is almost exactly 4T (and also way wrong, df reports 9.9T). Anyway, given the numbers it looks like some sort of maxint issue. Does anyone know if there is a fix? From mmcgrath at redhat.com Wed Apr 16 23:29:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 Apr 2008 18:29:48 -0500 (CDT) Subject: =?iso-8859-15?q?Re=3A_Self-Introduction=3A_Diego_B=FArigo_Zacar?= =?iso-8859-15?q?=E3o?= In-Reply-To: <6600c1b10804160550j76873af9qca8533ffa5917205@mail.gmail.com> References: <6600c1b10804160550j76873af9qca8533ffa5917205@mail.gmail.com> Message-ID: On Wed, 16 Apr 2008, Diego B?rigo Zacar?o wrote: > Hello, all! > > I have been contributing with Fedora Project for years, mainly as Ambassador > and Translator. Now, I'm running around the web development. Currently I'm > working on some Transifex enhancements and that drives me to be the newest > member of Fedora Infrastructure Projetc. > > I'm glad to be here! ;) > Welcome Diego! We're glad to have more help with Transifex. -Mike From mmcgrath at redhat.com Wed Apr 16 23:30:54 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 Apr 2008 18:30:54 -0500 (CDT) Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: <20080416200756.GA29076@Max> References: <20080416200756.GA29076@Max> Message-ID: On Wed, 16 Apr 2008, Ricky Zhou wrote: > I'd like to update syncStatic.sh to enforce the website change freeze > (in case I accidentally run make push). Here is the patch for the > change: > > Index: syncStatic.sh > =================================================================== > RCS file: /cvs/puppet/configs/system/syncStatic.sh,v > retrieving revision 1.20 > diff -u -r1.20 syncStatic.sh > --- syncStatic.sh 12 Dec 2007 23:11:07 -0000 1.20 > +++ syncStatic.sh 16 Apr 2008 20:06:34 -0000 > @@ -22,7 +22,8 @@ > cd $TEMP > /usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > > /dev/null 2>&1 > cd fedora-web > -/usr/bin/git checkout origin/live > /dev/null 2>&1 > +# Checkout last F8 commit > +/usr/bin/git checkout 091d53ea83b78e7a5ea2933be9100e74359802ee > > /dev/null 2>&1 > > cd fedoraproject.org > /bin/rm -rf /var/lib/puppet/application/fedoraproject.org/* > > What do you think? > Ricky I think this is fine. Actually if you get a moment can you add this to our SOP under tickets to be filed so we do it automatically as part of the next release? -Mike From mmcgrath at redhat.com Wed Apr 16 23:33:03 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 Apr 2008 18:33:03 -0500 (CDT) Subject: cacti misreports koji disk space In-Reply-To: <48067A8E.7030802@redhat.com> References: <48067A8E.7030802@redhat.com> Message-ID: dgilmore was working on this just recently (for proper monitoring of /mnt/koji) We'll have to ping him when he gets back from paradi^H^H^H^H^H^H Brazil. -Mike On Wed, 16 Apr 2008, Mike McLean wrote: > For a while I would look at the /mnt/koji space graph in Cacti and say to > myself "boy, garbage collection sure has managed to slow the growth in space > usage." The graph was really leveling off. > > https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=280 > > But then I realized: it's too level. If you get the csv data from Cacti, the > numbers for the last few months are identical. The data shows 2.1990232545e+12 > used, which is suspiciously close to exactly 2T (and wrong, df reports 2.7T). > The free space is stuck at the same number. Oddly the total space is reported > as 4.3980465091e+12, which is almost exactly 4T (and also way wrong, df > reports 9.9T). > > Anyway, given the numbers it looks like some sort of maxint issue. Does anyone > know if there is a fix? > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From seth.dawson at gmail.com Thu Apr 17 00:39:00 2008 From: seth.dawson at gmail.com (Seth Dawson) Date: Wed, 16 Apr 2008 19:39:00 -0500 Subject: New Message-ID: Hey, I'm new to the Fedora Project, I'm teaching myself Python and C++, I have experience with VB. Just wanted to say Hello and see if there was a good place for me to start contributing. Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmcgrath at redhat.com Thu Apr 17 00:49:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 Apr 2008 19:49:40 -0500 (CDT) Subject: New In-Reply-To: References: Message-ID: On Wed, 16 Apr 2008, Seth Dawson wrote: > Hey, I'm new to the Fedora Project, I'm teaching myself Python and C++, I > have experience with VB. Just wanted to say Hello and see if there was a > good place for me to start contributing. > Welcome! As a coder you might do well to join the BugZappers group: http://fedoraproject.org/wiki/BugZappers But lots of Fedora teams need programmers so I'm sure you'll find a home soon. -Mike From Matt_Domsch at dell.com Thu Apr 17 03:13:47 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 16 Apr 2008 22:13:47 -0500 Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: References: <20080416200756.GA29076@Max> Message-ID: <20080417031347.GA1612@auslistsprd01.us.dell.com> On Wed, Apr 16, 2008 at 06:30:54PM -0500, Mike McGrath wrote: > On Wed, 16 Apr 2008, Ricky Zhou wrote: > > > I'd like to update syncStatic.sh to enforce the website change freeze > > (in case I accidentally run make push). Here is the patch for the > > change: > > > > Index: syncStatic.sh > > =================================================================== > > RCS file: /cvs/puppet/configs/system/syncStatic.sh,v > > retrieving revision 1.20 > > diff -u -r1.20 syncStatic.sh > > --- syncStatic.sh 12 Dec 2007 23:11:07 -0000 1.20 > > +++ syncStatic.sh 16 Apr 2008 20:06:34 -0000 > > @@ -22,7 +22,8 @@ > > cd $TEMP > > /usr/bin/git clone git://git.fedorahosted.org/git/fedora-web.git > > > /dev/null 2>&1 > > cd fedora-web > > -/usr/bin/git checkout origin/live > /dev/null 2>&1 > > +# Checkout last F8 commit > > +/usr/bin/git checkout 091d53ea83b78e7a5ea2933be9100e74359802ee > > > /dev/null 2>&1 > > > > cd fedoraproject.org > > /bin/rm -rf /var/lib/puppet/application/fedoraproject.org/* > > > > What do you think? > > Ricky > > > I think this is fine. Actually if you get a moment can you add this to > our SOP under tickets to be filed so we do it automatically as part of the > next release? How about making a tag on that commit so the script is readable? :-) git tag -a fedora-8 091d53ea83b78e7a5ea2933be9100e74359802ee git checkout fedora-8 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ricky at fedoraproject.org Thu Apr 17 04:15:33 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 17 Apr 2008 00:15:33 -0400 Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: <20080417031347.GA1612@auslistsprd01.us.dell.com> References: <20080416200756.GA29076@Max> <20080417031347.GA1612@auslistsprd01.us.dell.com> Message-ID: <20080417041533.GA13300@Max> On 2008-04-16 10:13:47 PM, Matt Domsch wrote: > > I think this is fine. Actually if you get a moment can you add this to > > our SOP under tickets to be filed so we do it automatically as part of the > > next release? > > How about making a tag on that commit so the script is readable? :-) > > git tag -a fedora-8 091d53ea83b78e7a5ea2933be9100e74359802ee > git checkout fedora-8 Ah, good idea :) - that's done now (and mentioned on the release SOP). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Thu Apr 17 04:32:08 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 16 Apr 2008 23:32:08 -0500 Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: <20080417041533.GA13300@Max> References: <20080416200756.GA29076@Max> <20080417031347.GA1612@auslistsprd01.us.dell.com> <20080417041533.GA13300@Max> Message-ID: <20080417043208.GC1612@auslistsprd01.us.dell.com> On Thu, Apr 17, 2008 at 12:15:33AM -0400, Ricky Zhou wrote: > On 2008-04-16 10:13:47 PM, Matt Domsch wrote: > > > I think this is fine. Actually if you get a moment can you add this to > > > our SOP under tickets to be filed so we do it automatically as part of the > > > next release? > > > > How about making a tag on that commit so the script is readable? :-) > > > > git tag -a fedora-8 091d53ea83b78e7a5ea2933be9100e74359802ee > > git checkout fedora-8 > Ah, good idea :) - that's done now (and mentioned on the release SOP). Are you also making sure that the website content is getting copied out to the mirror space pub/fedora/web/ ? Perhaps less of a concern now that we have proxies scattered around the world, but the original thought was to have that content available on mirrors (30 or so are carrying it, and it's small, ~1MB) in case we needed to start redirecting at them in an emergency. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ricky at fedoraproject.org Thu Apr 17 10:52:01 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 17 Apr 2008 06:52:01 -0400 Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: <20080417043208.GC1612@auslistsprd01.us.dell.com> References: <20080416200756.GA29076@Max> <20080417031347.GA1612@auslistsprd01.us.dell.com> <20080417041533.GA13300@Max> <20080417043208.GC1612@auslistsprd01.us.dell.com> Message-ID: <20080417105201.GA5500@Max> On 2008-04-16 11:32:08 PM, Matt Domsch wrote: > Are you also making sure that the website content is getting copied > out to the mirror space pub/fedora/web/ ? Perhaps less of a concern > now that we have proxies scattered around the world, but the original > thought was to have that content available on mirrors (30 or so are > carrying it, and it's small, ~1MB) in case we needed to start > redirecting at them in an emergency. I thought we agreed not to worry about getting it on the mirrors this time around (although I could be mistaken). If we do decide to do this, what would be the deadline for having the pages ready? Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Apr 17 12:18:17 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Apr 2008 07:18:17 -0500 (CDT) Subject: Change freeze request: Enforce website freeze in syncStatic.sh In-Reply-To: <20080417105201.GA5500@Max> References: <20080416200756.GA29076@Max> <20080417031347.GA1612@auslistsprd01.us.dell.com> <20080417041533.GA13300@Max> <20080417043208.GC1612@auslistsprd01.us.dell.com> <20080417105201.GA5500@Max> Message-ID: On Thu, 17 Apr 2008, Ricky Zhou wrote: > On 2008-04-16 11:32:08 PM, Matt Domsch wrote: > > Are you also making sure that the website content is getting copied > > out to the mirror space pub/fedora/web/ ? Perhaps less of a concern > > now that we have proxies scattered around the world, but the original > > thought was to have that content available on mirrors (30 or so are > > carrying it, and it's small, ~1MB) in case we needed to start > > redirecting at them in an emergency. > I thought we agreed not to worry about getting it on the mirrors this > time around (although I could be mistaken). If we do decide to do this, > what would be the deadline for having the pages ready? > Yeah we kind of talked about it but I'm not sure if we came to a "total" conclusion. It's much less of a concern now since we actually have multiple sites to rely on. The last release didn't get anywhere close to needing to convert to a mirror site though I do like backup plans... -Mike From stickster at gmail.com Thu Apr 17 21:00:51 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 17 Apr 2008 17:00:51 -0400 Subject: Self-Introduction: =?iso-8859-1?q?Diego_B=FArigo_Zacar=E3o?= In-Reply-To: References: <6600c1b10804160550j76873af9qca8533ffa5917205@mail.gmail.com> Message-ID: <20080417210051.GB20055@localhost.localdomain> On Wed, Apr 16, 2008 at 06:29:48PM -0500, Mike McGrath wrote: > On Wed, 16 Apr 2008, Diego B?rigo Zacar?o wrote: > > > Hello, all! > > > > I have been contributing with Fedora Project for years, mainly as Ambassador > > and Translator. Now, I'm running around the web development. Currently I'm > > working on some Transifex enhancements and that drives me to be the newest > > member of Fedora Infrastructure Projetc. > > > > I'm glad to be here! ;) > > > > > Welcome Diego! We're glad to have more help with Transifex. Diego has been involved for quite a while as a very effective translator of Fedora into Brazilian Portuguese. Thanks, Diego, for your willingness to get involved in all sorts of pieces of Fedora! :-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Apr 17 21:07:32 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 17 Apr 2008 14:07:32 -0700 Subject: Meeting Log - 2008-04-17 Message-ID: <4807BC14.1040003@gmail.com> (01:03:22 PM) abadger1999 has changed the topic to: ?Fedora Infrastructure Meeting (01:03:42 PM) abadger1999: Alrighty! Meeting starting (01:03:48 PM) gkrpan: <-- here (01:04:06 PM) ivazquez: Present. (01:04:17 PM) ***iWolf lurks (01:04:18 PM) wolfy left the room ("Make every day good to the last drop.. nobody gets out alive in the end anyway!"). (01:04:46 PM) abadger1999: f13: ping (01:05:24 PM) abadger1999: We don't have too much today. (01:05:32 PM) abadger1999: Change Freeze is in effect. (01:05:32 PM) f13: pong (01:05:55 PM) abadger1999: So remember if you have a change you need please email the list before making it live. (01:06:32 PM) abadger1999: f13: Could you give us a summary of FESCo's meeting today and what things we need to be watching in Infrastructure? (01:06:57 PM) abadger1999 has changed the topic to: Fedora Infrastructure: FESCo, release, etc (01:07:12 PM) f13: FESCo decided to introduce a 2 week slip of the Fedora 9 schedule (01:07:44 PM) f13: this is mostly to allow Preview Release some time to be consumed and gather reports back, and also to take into account that a good chunk of X team is out this week and some of next at a conference, and I'm out the last week of April (01:07:59 PM) f13: nothing other than dates should really change for Infrastructure (01:08:27 PM) abadger1999: Sounds good. (01:09:28 PM) f13: PReview Release is about to be made available via torrents (01:09:43 PM) f13: and I'm going to also stage it for mirrors so that we can offer jigdo (01:09:52 PM) f13: that will be made available early next week (01:10:15 PM) abadger1999: What is the new release date going to be? (01:10:41 PM) f13: May 13 (01:11:39 PM) abadger1999: Okay. We'll need to update the counter on our website. (01:12:17 PM) abadger1999: and extend the freeze. (possibly shorten on this end, possibly not.) (01:12:40 PM) abadger1999: Anyone else have questions? (01:13:03 PM) abadger1999: f13: Thanks for the update! (01:13:13 PM) f13: np, I have to run for a bit (01:13:22 PM) abadger1999 has changed the topic to: Fedora Infrastructure Meeting: Tickets (01:13:32 PM) abadger1999: Okay, we only a have a few meeting tickets this week. (01:13:40 PM) abadger1999: jcollie: ping? rahul_b rdieter RenaultR83 ricky rsc rahul_b rdieter RenaultR83 ricky rsc (01:14:28 PM) RenaultR83 left the room (quit: Connection timed out). (01:14:40 PM) RenaultR83 [n=couretca at AToulon-151-1-7-46.w83-197.abo.wanadoo.fr] entered the room. (01:15:29 PM) abadger1999: Okay. So no update on audio conferencing via asterisk (01:15:55 PM) abadger1999: .ticket 398 (01:15:57 PM) zodbot: abadger1999: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 (01:16:20 PM) abadger1999: The monotone bug has been up for a while. I noticed that the upstream bug has a link to a program thatmight help. (01:17:01 PM) abadger1999: I've asked rmcgrath to evaluate whether usher will do what we need. (01:17:14 PM) abadger1999: .ticket 446 (01:17:15 PM) zodbot: abadger1999: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 (01:17:45 PM) abadger1999: It looks like we need to find a good way to link to the external spins that people are producing. (01:18:07 PM) yingbull [n=yingbull at S01060013104275dd.ss.shawcable.net] entered the room. (01:18:22 PM) abadger1999: There's likely to be quite a few which are localizations of the main Fedora Spin. (01:18:31 PM) ***yingbull arrives. (01:18:58 PM) abadger1999: Hey yingbull (01:19:16 PM) abadger1999: Does websites control spins.fp.o? (01:19:48 PM) abadger1999: How do they feel about designing something to link to external spins? Better to have a link to the wiki as dgilmore suggests? (01:20:15 PM) abadger1999: ricky, ivazquez: Thoughts? (01:21:13 PM) ivazquez: Restricting the links on the page to internal torrents does simplify things, but not by a lot. Personally I have no preference for or against. (01:21:25 PM) mdomsch [n=Matt_Dom at cpe-70-124-62-55.austin.res.rr.com] entered the room. (01:22:01 PM) Stalwart left the room (quit: Connection timed out). (01:22:23 PM) abadger1999: mdomsch: The logs so far: http://fpaste.org/paste/1796 (01:23:15 PM) tibbs left the room (quit: "Konversation terminated!"). (01:23:18 PM) abadger1999: Okay. So if we put them into the page directly we need to have people get the information to you to update the page. (01:23:30 PM) abadger1999: Does a ticket work best for that? (01:24:12 PM) ivazquez: Well, having said that, the infrastructure for supporting "off-site" spins isn't in place. (01:24:38 PM) abadger1999: Ah. Okay. So let's put this on hold until mmcgrath can fill in some of the blanks. (01:24:48 PM) ivazquez: Currently it uses the original page-generation script which I don't believe can handle that. (01:25:25 PM) ivazquez: (and I admittedly don't know enough about FI to poke at it) (01:25:45 PM) abadger1999: Alrighty. (01:25:56 PM) abadger1999 has changed the topic to: Fedora Infrastruture Meeting: Open Floor (01:26:10 PM) abadger1999: Anyone have any topics to discuss? (01:28:33 PM) abadger1999: I have one: With the two week slip of the release, we need to extend the change freeze. (01:28:58 PM) abadger1999: So, May 14th as the end date. (01:29:58 PM) abadger1999: Sound reasonable? Should we cut a bit off this end as well or has the burden not been to onerous on people? (01:30:18 PM) mdomsch: and we don't unfreeze now (01:30:55 PM) ivazquez: Do we want to be frozen for an entire month? (01:32:09 PM) ivazquez: Okay, I'm not hearing any one arguing that we shouldn't, so I'll live. (01:32:50 PM) ***abadger1999 notes that he doesn't care (01:33:08 PM) lmacken: sounds reasonable to me. (01:33:15 PM) lmacken: even though i'll probably have to break freeze for bodhi at some point :\ (01:33:38 PM) abadger1999: The change freeze was supposed to start two weeks before release. So if we unfreeze we'd push it back to Apr 29. (01:34:12 PM) abadger1999: If we stay frozen, we could be much more liberal with what we accept until that date... but then, what's the purpose of the freeze then? (01:34:16 PM) mdomsch: freeze + exceptions is sane (01:34:28 PM) mdomsch: just get exceptions reviewed (01:35:50 PM) bpepple left the room (quit: Read error: 110 (Connection timed out)). (01:35:53 PM) abadger1999: Okay. So proposal: Announce changes to the list. Reviewers know that we can continue to make more intrusive changes until Apr 29. So be liberal with the +1's until then. (01:37:51 PM) ivazquez: That seems acceptable to me. (01:38:02 PM) abadger1999: Alright. (01:38:05 PM) yingbull: Sounds fine by me, too. (01:38:42 PM) abadger1999: Oh one more announcement: f13 and I will be finalizing a plan for mass branching of cvs and branching this weekend. (01:39:26 PM) abadger1999: That means an outage for cvs commits. We'll send mail to fedora-devel-announce about that. (01:39:33 PM) abadger1999: Anyone else have anything? (01:39:52 PM) mdomsch: f13 just sent the announcement; I'll forward to the mirrors (01:42:26 PM) abadger1999: Okay. I'll close the meeting in 60 (01:42:52 PM) RenaultR83 left the room (quit: Read error: 110 (Connection timed out)). (01:44:22 PM) bpepple [n=bpepple at adsl-76-228-104-62.dsl.wotnoh.sbcglobal.net] entered the room. (01:46:28 PM) jwb is now known as jwb_gone (01:46:37 PM) abadger1999: Okay.Thanksall (01:46:49 PM) abadger1999 has changed the topic to: Topic for #fedora-meeting is 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/Communicate/FedoraMeetingChannel for meeting schedule -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Fri Apr 18 00:52:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Apr 2008 19:52:05 -0500 (CDT) Subject: Fedora 9 Release date slipping by two weeks (new date, May 13) (fwd) Message-ID: Looks like the release slipped meaning the new date is currently on May 13th. Jesse, with your blessing I'd like to remove the change freeze window and start it back up again on April 29th, to end on May 14th. Sound good? -Mike -------------- next part -------------- At today's regularly scheduled meeting, the Fedora Engineering Steering Committee (FESCo) decided that Fedora 9 release will be slipping by exactly two weeks. Because of other slippage, coupled with some technical difficulties during this previous week, our Preview Release was unexpectedly stalled. The Preview Release is where we expect to catch all manner of last-minute bugs, do very heavy QA, and otherwise perform all the final spit-and-polish. There needs to be sufficient time between the PR and the release for testers to find and report issues. There are less than two weeks remaining until the original target date of April 29th. About a week before that date we have to have everything locked and loaded for distribution by our mirrors. That small a timeframe would then make the Preview Release -- normally a very important part of our release schedule -- nearly useless. This slip is not intended to make room for more changes, it is only intended to make room for fixing the things we already know about, and allowing new things to be found, and evaluated as release blocking, and fixed. There are also a fair number of bugs we think we've already fixed, but need wider audience testing to be sure. The current blocker list is viewable at https://bugzilla.redhat.com/showdependencytree.cgi?id=235706&hide_resolved=1 however since there is nothing preventing people from adding bugs to this list it will get culled from time to time from things that aren't actually blockers. A (rather longer) list of things we'd like to see fixes for can be seen https://bugzilla.redhat.com/showdependencytree.cgi?id=235705&hide_resolved=1 although this list does get less attention than the blocker list. We deeply appreciate the value we get from our community in using our development tree and testing our release attempts. Without your input, our releases couldn't possibly be as good as they have been. Please help us use these extra couple of weeks to make the already awesome Fedora 9 even better! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mmcgrath at redhat.com Fri Apr 18 00:54:54 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 Apr 2008 19:54:54 -0500 (CDT) Subject: Fedora 9 Release date slipping by two weeks (new date, May 13) (fwd) In-Reply-To: References: Message-ID: On Thu, 17 Apr 2008, Mike McGrath wrote: > Looks like the release slipped meaning the new date is currently on May > 13th. > > Jesse, with your blessing I'd like to remove the change freeze window and > start it back up again on April 29th, to end on May 14th. Sound good? > I see this was already discussed in the meeting (slow to catch up on emails today) Please disregard my previous message. -Mike From Matt_Domsch at dell.com Fri Apr 18 15:59:39 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 18 Apr 2008 10:59:39 -0500 Subject: lists.fp.o catch and redirect Message-ID: <20080418155939.GA21819@auslistsprd01.us.dell.com> right now lists.fp.o is a DNS CNAME to www.redhat.com. This is a bit odd as hitting lists.fp.o/ gives you redhat.com. Shawn Starr noted this. I've put into CVS a new lists.fedoraproject.org.conf and redirect directory, have a look. The rewrites do: RewriteRule ^/$ https://www.redhat.com/mailman/listinfo [R,L] RewriteRule ^/archives(.*) https://www.redhat.com/archives$1 [R,L] RewriteRule ^/mailman(.*) https://www.redhat.com/mailman$1 [R,L] With this, hitting lists.fp.o will take you to the listinfo page directly, which is nicer behavior. And the long-term URLs for /mailman and /archives will redirect too. Objections? The last change will be to move the DNS CNAME from www.redhat.com to fedoraproject.org. I haven't done this yet, waiting on acks. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Fri Apr 18 18:48:43 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 13:48:43 -0500 (CDT) Subject: lists.fp.o catch and redirect In-Reply-To: <20080418155939.GA21819@auslistsprd01.us.dell.com> References: <20080418155939.GA21819@auslistsprd01.us.dell.com> Message-ID: On Fri, 18 Apr 2008, Matt Domsch wrote: > right now lists.fp.o is a DNS CNAME to www.redhat.com. This is a bit > odd as hitting lists.fp.o/ gives you redhat.com. > > Shawn Starr noted this. I've put into CVS a new > lists.fedoraproject.org.conf and redirect directory, have a look. > The rewrites do: > > RewriteRule ^/$ https://www.redhat.com/mailman/listinfo [R,L] > RewriteRule ^/archives(.*) https://www.redhat.com/archives$1 [R,L] > RewriteRule ^/mailman(.*) https://www.redhat.com/mailman$1 [R,L] > > With this, hitting lists.fp.o will take you to the listinfo page > directly, which is nicer behavior. And the long-term URLs for > /mailman and /archives will redirect too. > > Objections? > > The last change will be to move the DNS CNAME from www.redhat.com to > fedoraproject.org. I haven't done this yet, waiting on acks. > No objections here. -Mike From skvidal at fedoraproject.org Fri Apr 18 20:09:52 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 18 Apr 2008 16:09:52 -0400 Subject: xen proposal Message-ID: <1208549392.8793.10.camel@cutter> So xen1 went down today and I was helping bring things back up. I didn't know to look in /var/log/messages for the messages from xenGuestsRunning.sh. I was wondering this: would it make sense to have xenGuestsRunning run every hour and re-make the symlinks in /etc/xen/auto for the guests which should be running on the machine? Also - if for some reason the xen guests can't be started up automatically due to other complexities (iscsi, memory over commit, etc) we could have xenGuestsrunning auto-generate a script which can be run to re-make the xen guests which should be running. I'd be willing to put the script together, I just wanted to ask if there was a good reason NOT to do this, so I don't waste time if I've missed something. thanks, -sv -- I only speak for me. From mmcgrath at redhat.com Fri Apr 18 20:33:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 15:33:22 -0500 (CDT) Subject: xen proposal In-Reply-To: <1208549392.8793.10.camel@cutter> References: <1208549392.8793.10.camel@cutter> Message-ID: On Fri, 18 Apr 2008, seth vidal wrote: > So xen1 went down today and I was helping bring things back up. I didn't > know to look in /var/log/messages for the messages from > xenGuestsRunning.sh. I was wondering this: > > would it make sense to have xenGuestsRunning run every hour and re-make > the symlinks in /etc/xen/auto for the guests which should be running on > the machine? Also - if for some reason the xen guests can't be started > up automatically due to other complexities (iscsi, memory over commit, > etc) we could have xenGuestsrunning auto-generate a script which can be > run to re-make the xen guests which should be running. > > I'd be willing to put the script together, I just wanted to ask if there > was a good reason NOT to do this, so I don't waste time if I've missed > something. > The only reason we haven't done this already is the inability to detect if the box is already up somewhere (which is something we need already) Consider this scenario: app1 running on xen1 (which is having high load from koji1 also on xen1) People complain about the wiki. We move app1 to a more free box, xen7. high load causes CRASH xen1 reboots. Attempts to bring app1 up (already up on xen7) Two machines try to write to the same disk - DOOM. There is a bit of hope in this. 1) its happened before and it seems that the second guest sees the disk is already mounted and gets stuck at an fsck shell. As long as we realize that that condition potentially means the box is already up and needs to be checked... we're fine. If someone tries to type the root password and fsck the disk... DOOM. This is all a sign of a larger problem with the lack of open source management tools for virtualization on more then one host at a time. I'm a huge fan of automation so in general I'd like to see the plan above implemented but I think we need to alter the xm creation scripts (I'm not sure what this involves) that makes sure hosts don't come up on the wrong xen host. -Mike From mmcgrath at redhat.com Fri Apr 18 20:34:24 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 15:34:24 -0500 (CDT) Subject: Change request (xen1) Message-ID: Since we're back to more invasive changes I'd like to install the rhel 5.2 beta kernel on xen1 and reboot it. It died today and I suspect this is because of iscsi issues we've seen before (rare, but still happening) -Mike From mmcgrath at redhat.com Fri Apr 18 20:35:09 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 15:35:09 -0500 (CDT) Subject: Change Request (app5) Message-ID: I'd like to spend the rest of our non firm change window to try to get app5 in order. If I'm unable I'd like to revert it to the x86_64 image (still on the box) until after the release. -Mike From mmcgrath at redhat.com Fri Apr 18 20:41:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 15:41:27 -0500 (CDT) Subject: xen proposal In-Reply-To: <1208549392.8793.10.camel@cutter> References: <1208549392.8793.10.camel@cutter> Message-ID: On Fri, 18 Apr 2008, seth vidal wrote: > So xen1 went down today and I was helping bring things back up. I didn't > know to look in /var/log/messages for the messages from > xenGuestsRunning.sh. I was wondering this: > One more got'cha we need to fix is at some point in time xen stopped honoring the MAXMEM setting and wouldn't let guests go above the default mem setting. This caused some of our xen configs to get overcommitted (total memory size is greater then the memory on the box and upon starting we'd have to xm mem-set some of the boxes lower) I'm almost positive this is fixed now so we can go through, set mem to something lower and have maxmem behave properly. -Mike From skvidal at fedoraproject.org Fri Apr 18 20:42:45 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 18 Apr 2008 16:42:45 -0400 Subject: xen proposal In-Reply-To: References: <1208549392.8793.10.camel@cutter> Message-ID: <1208551365.8793.15.camel@cutter> On Fri, 2008-04-18 at 15:33 -0500, Mike McGrath wrote: > The only reason we haven't done this already is the inability to detect if > the box is already up somewhere (which is something we need already) > Consider this scenario: > > app1 running on xen1 (which is having high load from koji1 also on xen1) > > People complain about the wiki. > > We move app1 to a more free box, xen7. > > high load causes CRASH > > xen1 reboots. Attempts to bring app1 up (already up on xen7) > > Two machines try to write to the same disk - DOOM. > > > There is a bit of hope in this. 1) its happened before and it seems > that the second guest sees the disk is already mounted and gets stuck at > an fsck shell. As long as we realize that that condition potentially > means the box is already up and needs to be checked... we're fine. If > someone tries to type the root password and fsck the disk... DOOM. > > This is all a sign of a larger problem with the lack of open source > management tools for virtualization on more then one host at a time. I'm > a huge fan of automation so in general I'd like to > see the plan above implemented but I think we need to alter the xm > creation scripts (I'm not sure what this involves) that makes sure hosts > don't come up on the wrong xen host. > Okay so maybe we need a really-xen-startup init script which: 1. happens AFTER network, etc are up so iscsi items work 2. provides a locking capability so it can talk to 'something else' to find out which domains are already locked and allocated to determine if it should start them (and this is easy to circumvent stale locks on crashing with a good db) 3. notifies on restart. just a few thoughts... thanks -sv From k.georgiou at imperial.ac.uk Fri Apr 18 20:52:38 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 18 Apr 2008 21:52:38 +0100 Subject: xen proposal In-Reply-To: References: <1208549392.8793.10.camel@cutter> Message-ID: <20080418205238.GA4991@imperial.ac.uk> On Fri, Apr 18, 2008 at 03:33:22PM -0500, Mike McGrath wrote: > The only reason we haven't done this already is the inability to detect if > the box is already up somewhere (which is something we need already) > Consider this scenario: > > app1 running on xen1 (which is having high load from koji1 also on xen1) > > People complain about the wiki. > > We move app1 to a more free box, xen7. > > high load causes CRASH > > xen1 reboots. Attempts to bring app1 up (already up on xen7) > > Two machines try to write to the same disk - DOOM. What about using gfs (or maybe just nfs from the netapp) to keep the contents of /etc/xen/auto "synced" between hosts? Having /etc/xen/auto as a link to [sharedarea]/auto-xenXX and making sure that the entries there are unique will be a good start for a solution I think. Kostas From jkeating at redhat.com Fri Apr 18 20:57:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Apr 2008 16:57:44 -0400 Subject: Change request (xen1) In-Reply-To: References: Message-ID: <1208552264.3445.63.camel@localhost.localdomain> On Fri, 2008-04-18 at 15:34 -0500, Mike McGrath wrote: > Since we're back to more invasive changes I'd like to install the rhel 5.2 > beta kernel on xen1 and reboot it. It died today and I suspect this is > because of iscsi issues we've seen before (rare, but still happening) +1, I assume that this might be sometime over the weekend, and we could coordinate with the CVS outage? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Fri Apr 18 20:59:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 15:59:27 -0500 (CDT) Subject: Change request (xen1) In-Reply-To: <1208552264.3445.63.camel@localhost.localdomain> References: <1208552264.3445.63.camel@localhost.localdomain> Message-ID: On Fri, 18 Apr 2008, Jesse Keating wrote: > On Fri, 2008-04-18 at 15:34 -0500, Mike McGrath wrote: > > Since we're back to more invasive changes I'd like to install the rhel 5.2 > > beta kernel on xen1 and reboot it. It died today and I suspect this is > > because of iscsi issues we've seen before (rare, but still happening) > > > +1, I assume that this might be sometime over the weekend, and we could > coordinate with the CVS outage? > the only two outages here will be transifex and koji. -Mike From a.badger at gmail.com Fri Apr 18 21:33:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 18 Apr 2008 14:33:31 -0700 Subject: Change request (xen1) In-Reply-To: References: Message-ID: <480913AB.1030105@gmail.com> Mike McGrath wrote: > Since we're back to more invasive changes I'd like to install the rhel 5.2 > beta kernel on xen1 and reboot it. It died today and I suspect this is > because of iscsi issues we've seen before (rare, but still happening) > +1. If we can fix that it would be a big help. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Fri Apr 18 21:38:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 18 Apr 2008 14:38:31 -0700 Subject: Change Request (app5) In-Reply-To: References: Message-ID: <480914D7.6060801@gmail.com> Mike McGrath wrote: > I'd like to spend the rest of our non firm change window to try to get > app5 in order. If I'm unable I'd like to revert it to the x86_64 image > (still on the box) until after the release. > +1. When would be the drop dead date to revert? Friday before the hard freeze? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Fri Apr 18 21:39:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 16:39:18 -0500 (CDT) Subject: xen proposal In-Reply-To: <20080418205238.GA4991@imperial.ac.uk> References: <1208549392.8793.10.camel@cutter> <20080418205238.GA4991@imperial.ac.uk> Message-ID: On Fri, 18 Apr 2008, Kostas Georgiou wrote: > On Fri, Apr 18, 2008 at 03:33:22PM -0500, Mike McGrath wrote: > > > The only reason we haven't done this already is the inability to detect if > > the box is already up somewhere (which is something we need already) > > Consider this scenario: > > > > app1 running on xen1 (which is having high load from koji1 also on xen1) > > > > People complain about the wiki. > > > > We move app1 to a more free box, xen7. > > > > high load causes CRASH > > > > xen1 reboots. Attempts to bring app1 up (already up on xen7) > > > > Two machines try to write to the same disk - DOOM. > > What about using gfs (or maybe just nfs from the netapp) to keep the > contents of /etc/xen/auto "synced" between hosts? Having /etc/xen/auto > as a link to [sharedarea]/auto-xenXX and making sure that the entries > there are unique will be a good start for a solution I think. > Network file shares are ill suited for tasks like configuration management IMHO. -Mike From Matt_Domsch at dell.com Fri Apr 18 21:40:34 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 18 Apr 2008 16:40:34 -0500 Subject: lists.fp.o catch and redirect In-Reply-To: References: <20080418155939.GA21819@auslistsprd01.us.dell.com> Message-ID: <20080418214034.GC21819@auslistsprd01.us.dell.com> On Fri, Apr 18, 2008 at 01:48:43PM -0500, Mike McGrath wrote: > > On Fri, 18 Apr 2008, Matt Domsch wrote: > > > right now lists.fp.o is a DNS CNAME to www.redhat.com. This is a bit > > odd as hitting lists.fp.o/ gives you redhat.com. > > > > Shawn Starr noted this. I've put into CVS a new > > lists.fedoraproject.org.conf and redirect directory, have a look. > > The rewrites do: > > > > RewriteRule ^/$ https://www.redhat.com/mailman/listinfo [R,L] > > RewriteRule ^/archives(.*) https://www.redhat.com/archives$1 [R,L] > > RewriteRule ^/mailman(.*) https://www.redhat.com/mailman$1 [R,L] > > > > With this, hitting lists.fp.o will take you to the listinfo page > > directly, which is nicer behavior. And the long-term URLs for > > /mailman and /archives will redirect too. > > > > Objections? > > > > The last change will be to move the DNS CNAME from www.redhat.com to > > fedoraproject.org. I haven't done this yet, waiting on acks. > > > > No objections here. Changes pushed, yell if it breaks. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From k.georgiou at imperial.ac.uk Fri Apr 18 22:25:08 2008 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Fri, 18 Apr 2008 23:25:08 +0100 Subject: xen proposal In-Reply-To: References: <1208549392.8793.10.camel@cutter> <20080418205238.GA4991@imperial.ac.uk> Message-ID: <20080418222508.GA6136@imperial.ac.uk> On Fri, Apr 18, 2008 at 04:39:18PM -0500, Mike McGrath wrote: > On Fri, 18 Apr 2008, Kostas Georgiou wrote: > > > On Fri, Apr 18, 2008 at 03:33:22PM -0500, Mike McGrath wrote: > > > > > The only reason we haven't done this already is the inability to detect if > > > the box is already up somewhere (which is something we need already) > > > Consider this scenario: > > > > > > app1 running on xen1 (which is having high load from koji1 also on xen1) > > > > > > People complain about the wiki. > > > > > > We move app1 to a more free box, xen7. > > > > > > high load causes CRASH > > > > > > xen1 reboots. Attempts to bring app1 up (already up on xen7) > > > > > > Two machines try to write to the same disk - DOOM. > > > > What about using gfs (or maybe just nfs from the netapp) to keep the > > contents of /etc/xen/auto "synced" between hosts? Having /etc/xen/auto > > as a link to [sharedarea]/auto-xenXX and making sure that the entries > > there are unique will be a good start for a solution I think. > > > > Network file shares are ill suited for tasks like configuration management > IMHO. I don't disagree, I don't like it either. RedHat magazine had an article[1] recently about xen failover using conga. It might give some ideas even if you prefer not to use gfs (probably a bad idea to have host images in gfs anyway). Kostas [1] http://www.redhatmagazine.com/2007/08/23/automated-failover-and-recovery-of-virtualized-guests-in-advanced-platform From mmcgrath at redhat.com Fri Apr 18 23:14:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 18 Apr 2008 18:14:56 -0500 (CDT) Subject: xen proposal In-Reply-To: <20080418222508.GA6136@imperial.ac.uk> References: <1208549392.8793.10.camel@cutter> <20080418205238.GA4991@imperial.ac.uk> <20080418222508.GA6136@imperial.ac.uk> Message-ID: On Fri, 18 Apr 2008, Kostas Georgiou wrote: > > Kostas > > [1] http://www.redhatmagazine.com/2007/08/23/automated-failover-and-recovery-of-virtualized-guests-in-advanced-platform > I'd played a little bit with this not too long ago actually but found luci / ricci to be a bit to tempermental for that particular job. Plus there's no need for gfs / nfs in that particular instance if you're using clvm. -Mike From mmcgrath at redhat.com Sat Apr 19 16:14:17 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 19 Apr 2008 11:14:17 -0500 (CDT) Subject: Change (already) - steved In-Reply-To: References: Message-ID: On Tue, 15 Apr 2008, Mike McGrath wrote: > One thing we'd been talking about before the freeze but just didn't get > around to was giving steved (nfs expert) access to our nfs box where > /mnt/koji lives as we still seem to be having nfslock issues (though they > are less frequent now). > This is done. -Mike From mmcgrath at redhat.com Sat Apr 19 16:27:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 19 Apr 2008 11:27:40 -0500 (CDT) Subject: German Colo test server Message-ID: I'd like to get another test server up in the new datacenter for Frank et all to work on the wordpress deployment. This should have _no_ affect on anything but its a change in the freeze. Rules are rules :) -Mike From skvidal at fedoraproject.org Sat Apr 19 16:34:43 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 19 Apr 2008 12:34:43 -0400 Subject: German Colo test server In-Reply-To: References: Message-ID: <1208622883.8793.24.camel@cutter> On Sat, 2008-04-19 at 11:27 -0500, Mike McGrath wrote: > I'd like to get another test server up in the new datacenter for Frank et > all to work on the wordpress deployment. This should have _no_ affect on > anything but its a change in the freeze. Rules are rules :) whew, for a moment I read that as wordperfect deployment and I could only thing NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! but since it is wordpress +1 -sv From ricky at fedoraproject.org Sat Apr 19 16:59:03 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 19 Apr 2008 12:59:03 -0400 Subject: Change freeze request: Add zh_CN on fedorahosted.org Message-ID: <20080419165903.GA6693@Max> I'd like to add zh_CN (and a few other languages) to the fedorahosted site (they're currently listed on the site, but does not work without these apache conf changes). Index: languages.conf =================================================================== RCS file: /cvs/puppet/configs/web/fedorahosted.org/languages.conf,v retrieving revision 1.4 diff -u -r1.4 languages.conf --- languages.conf 9 Mar 2008 20:40:18 -0000 1.4 +++ languages.conf 19 Apr 2008 16:58:31 -0000 @@ -4,22 +4,29 @@ AddLanguage de .de AddLanguage el .el AddLanguage en .en +AddLanguage es .es +AddLanguage hu .hu +AddLanguage id .id AddLanguage it .it AddLanguage pl .pl +AddLanguage ru .ru +AddLanguage sr .sr AddLanguage pt-br .pt_BR +AddLanguage zh-cn .zh_CN LanguagePriority en ForceLanguagePriority Prefer Fallback RewriteEngine on -RewriteCond %{QUERY_STRING} ^lang=(bal|de|el|en|it|pl|pt_BR)$ -RewriteRule ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))?(/.*)$ /web/%1$1? [R=301] -AliasMatch ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))(/.*)?$ /srv/web/fedorahosted.org$1 +RewriteCond %{QUERY_STRING} ^lang=(bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN)$ +RewriteRule ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))?(/.*)$ /web/%1$1? [R=301] +AliasMatch ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))(/.*)?$ /srv/web/fedorahosted.org$1 Options MultiViews - SetEnvIf Request_URI ^/web/(bal|de|el|en|it|pl)/ prefer-language=$1 + SetEnvIf Request_URI ^/web/(bal|de|el|en|es|hu|id|it|pl|ru|sr)/ prefer-language=$1 SetEnvIf Request_URI ^/web/pt_BR/ prefer-language=pt-br + SetEnvIf Request_URI ^/web/zh_CN/ prefer-language=zh-cn Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ricky at fedoraproject.org Sat Apr 19 17:00:32 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sat, 19 Apr 2008 13:00:32 -0400 Subject: German Colo test server In-Reply-To: References: Message-ID: <20080419170032.GA14422@Max> On 2008-04-19 11:27:40 AM, Mike McGrath wrote: > I'd like to get another test server up in the new datacenter for Frank et > all to work on the wordpress deployment. This should have _no_ affect on > anything but its a change in the freeze. Rules are rules :) +1 Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Sat Apr 19 17:22:41 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 19 Apr 2008 12:22:41 -0500 (CDT) Subject: Change freeze request: Add zh_CN on fedorahosted.org In-Reply-To: <20080419165903.GA6693@Max> References: <20080419165903.GA6693@Max> Message-ID: On Sat, 19 Apr 2008, Ricky Zhou wrote: > I'd like to add zh_CN (and a few other languages) to the fedorahosted > site (they're currently listed on the site, but does not work without > these apache conf changes). > > Index: languages.conf > =================================================================== > RCS file: /cvs/puppet/configs/web/fedorahosted.org/languages.conf,v > retrieving revision 1.4 > diff -u -r1.4 languages.conf > --- languages.conf 9 Mar 2008 20:40:18 -0000 1.4 > +++ languages.conf 19 Apr 2008 16:58:31 -0000 > @@ -4,22 +4,29 @@ > AddLanguage de .de > AddLanguage el .el > AddLanguage en .en > +AddLanguage es .es > +AddLanguage hu .hu > +AddLanguage id .id > AddLanguage it .it > AddLanguage pl .pl > +AddLanguage ru .ru > +AddLanguage sr .sr > AddLanguage pt-br .pt_BR > +AddLanguage zh-cn .zh_CN > > LanguagePriority en > ForceLanguagePriority Prefer Fallback > > RewriteEngine on > -RewriteCond %{QUERY_STRING} ^lang=(bal|de|el|en|it|pl|pt_BR)$ > -RewriteRule ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))?(/.*)$ /web/%1$1? > [R=301] > -AliasMatch ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))(/.*)?$ > /srv/web/fedorahosted.org$1 > +RewriteCond %{QUERY_STRING} > ^lang=(bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN)$ > +RewriteRule > ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))?(/.*)$ > /web/%1$1? [R=301] > +AliasMatch > ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))(/.*)?$ > /srv/web/fedorahosted.org$1 > > > Options MultiViews > > - SetEnvIf Request_URI ^/web/(bal|de|el|en|it|pl)/ prefer-language=$1 > + SetEnvIf Request_URI ^/web/(bal|de|el|en|es|hu|id|it|pl|ru|sr)/ > prefer-language=$1 > SetEnvIf Request_URI ^/web/pt_BR/ prefer-language=pt-br > + SetEnvIf Request_URI ^/web/zh_CN/ prefer-language=zh-cn > > +1 to this. -Mike From mmcgrath at redhat.com Sat Apr 19 17:28:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 19 Apr 2008 12:28:15 -0500 (CDT) Subject: change request (puppet-0.24.1-1.el5) Message-ID: Some of our boxes got updated with the newest version of puppet (0.24.4) I'd like to remove that version and install puppet-0.24.1-1.el5 since it actually works. Risk: low -Mike From dennis at ausil.us Sat Apr 19 17:47:18 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 19 Apr 2008 12:47:18 -0500 Subject: change request (puppet-0.24.1-1.el5) In-Reply-To: References: Message-ID: <200804191247.19160.dennis@ausil.us> On Saturday 19 April 2008, Mike McGrath wrote: > Some of our boxes got updated with the newest version of puppet (0.24.4) > I'd like to remove that version and install puppet-0.24.1-1.el5 since it > actually works. > > Risk: low > > -Mike +1 From dennis at ausil.us Sat Apr 19 17:47:41 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 19 Apr 2008 12:47:41 -0500 Subject: Change freeze request: Add zh_CN on fedorahosted.org In-Reply-To: References: <20080419165903.GA6693@Max> Message-ID: <200804191247.47376.dennis@ausil.us> On Saturday 19 April 2008, Mike McGrath wrote: > On Sat, 19 Apr 2008, Ricky Zhou wrote: > > I'd like to add zh_CN (and a few other languages) to the fedorahosted > > site (they're currently listed on the site, but does not work without > > these apache conf changes). > > > > Index: languages.conf > > =================================================================== > > RCS file: /cvs/puppet/configs/web/fedorahosted.org/languages.conf,v > > retrieving revision 1.4 > > diff -u -r1.4 languages.conf > > --- languages.conf 9 Mar 2008 20:40:18 -0000 1.4 > > +++ languages.conf 19 Apr 2008 16:58:31 -0000 > > @@ -4,22 +4,29 @@ > > AddLanguage de .de > > AddLanguage el .el > > AddLanguage en .en > > +AddLanguage es .es > > +AddLanguage hu .hu > > +AddLanguage id .id > > AddLanguage it .it > > AddLanguage pl .pl > > +AddLanguage ru .ru > > +AddLanguage sr .sr > > AddLanguage pt-br .pt_BR > > +AddLanguage zh-cn .zh_CN > > > > LanguagePriority en > > ForceLanguagePriority Prefer Fallback > > > > RewriteEngine on > > -RewriteCond %{QUERY_STRING} ^lang=(bal|de|el|en|it|pl|pt_BR)$ > > -RewriteRule ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))?(/.*)$ /web/%1$1? > > [R=301] > > -AliasMatch ^/web(?:/(?:bal|de|el|en|it|pl|pt_BR))(/.*)?$ > > /srv/web/fedorahosted.org$1 > > +RewriteCond %{QUERY_STRING} > > ^lang=(bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN)$ > > +RewriteRule > > ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))?(/.*)$ > > /web/%1$1? [R=301] > > +AliasMatch > > ^/web(?:/(?:bal|de|el|en|es|hu|id|it|pl|ru|sr|pt_BR|zh_CN))(/.*)?$ > > /srv/web/fedorahosted.org$1 > > > > > > Options MultiViews > > > > - SetEnvIf Request_URI ^/web/(bal|de|el|en|it|pl)/ prefer-language=$1 > > + SetEnvIf Request_URI ^/web/(bal|de|el|en|es|hu|id|it|pl|ru|sr)/ > > prefer-language=$1 > > SetEnvIf Request_URI ^/web/pt_BR/ prefer-language=pt-br > > + SetEnvIf Request_URI ^/web/zh_CN/ prefer-language=zh-cn > > > > +1 to this. > > -Mike +1 from me also Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From michael.yingbull at gmail.com Sat Apr 19 18:41:14 2008 From: michael.yingbull at gmail.com (Michael Yingbull) Date: Sat, 19 Apr 2008 12:41:14 -0600 Subject: Change freeze request: add error pages to domains that don't have them Message-ID: <8c0317740804191141l1d9a54f4v6a67e88964261c4e@mail.gmail.com> This was a change started before the freeze that Ricky and I worked on. http://www.fedoraproject.org/wronglink will give a nice custom 404 page, while other domains (such as start.fedoraproject.org) don't, just giving the default apache one (http://start.fedoraproject.org/wronglink). Ricky and I setup a /e/ directory that contains the multi language error pages, so that you can go to /e/404 and get the right 404 page in the right language. For the other domains that do not have a 404 error page configured, I'll add a 404.conf file to the apache conifg, alias /e/ to the same one as fp.o, and then set the error page for that domain to be /e/404. That would give the default fedora 404 page, and allow for MultiView to work so it will be in the right language. The same will be done for 500. mmcgrath and I have been talking about this over the last week and a half - since the change freeze is extended abit more, I'd like to wrap this up and have it in place. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Apr 19 19:05:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 19 Apr 2008 15:05:41 -0400 Subject: CVS Outage Message-ID: <1208631941.3445.88.camel@localhost.localdomain> In order to mass branch packages for F-9, we are enacting an outage of the CVS system. We sincerely apologize for not having any advanced warning of this outage. Delays in Fedora 9 Preview release made the scheduling of the mass branch uncertain. There will be an outage starting at 2008-04-19 18:00 UTC. Initial estimates show that 30 hours will be needed to complete the branching, however this may drastically be reduced during the full run. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-04-19 18:00 UTC UTC' Affected Services: Fedora CVS Unaffected Services: Everything that is not Fedora CVS. Reason for Outage: Mass branch for F-9. We need to disable change mail and ACL lookups to make the branching happen as fast as possible. Contact Information: Jesse Keating Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Apr 19 19:43:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 19 Apr 2008 12:43:01 -0700 Subject: Change freeze request: add error pages to domains that don't have them In-Reply-To: <8c0317740804191141l1d9a54f4v6a67e88964261c4e@mail.gmail.com> References: <8c0317740804191141l1d9a54f4v6a67e88964261c4e@mail.gmail.com> Message-ID: <480A4B45.9040707@gmail.com> Michael Yingbull wrote: > > This was a change started before the freeze that Ricky and I worked on. > > http://www.fedoraproject.org/wronglink will give a nice custom 404 page, > while other domains (such as start.fedoraproject.org > ) don't, just giving the default apache > one (http://start.fedoraproject.org/wronglink). > Ricky and I setup a /e/ directory that contains the multi language error > pages, so that you can go to /e/404 and get the right 404 page in the > right language. > > For the other domains that do not have a 404 error page configured, I'll > add a 404.conf file to the apache conifg, alias /e/ to the same one as > fp.o, and then set the error page for that domain to be /e/404. > That would give the default fedora 404 page, and allow for MultiView to > work so it will be in the right language. The same will be done for 500. > > mmcgrath and I have been talking about this over the last week and a > half - since the change freeze is extended abit more, I'd like to wrap > this up and have it in place. > > Thoughts? > This gets a +1 from me. Getting it on the servers so it has some time for people to test and report problems before the hard freeze (April 29) is highly desirable. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Sat Apr 19 22:50:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 19 Apr 2008 17:50:46 -0500 (CDT) Subject: Change freeze request: add error pages to domains that don't have them In-Reply-To: <480A4B45.9040707@gmail.com> References: <8c0317740804191141l1d9a54f4v6a67e88964261c4e@mail.gmail.com> <480A4B45.9040707@gmail.com> Message-ID: On Sat, 19 Apr 2008, Toshio Kuratomi wrote: > Michael Yingbull wrote: > > > > This was a change started before the freeze that Ricky and I worked on. > > http://www.fedoraproject.org/wronglink will give a nice custom 404 page, > > while other domains (such as start.fedoraproject.org > > ) don't, just giving the default apache one > > (http://start.fedoraproject.org/wronglink). > > Ricky and I setup a /e/ directory that contains the multi language error > > pages, so that you can go to /e/404 and get the right 404 page in the right > > language. > > > > For the other domains that do not have a 404 error page configured, I'll add > > a 404.conf file to the apache conifg, alias /e/ to the same one as fp.o, and > > then set the error page for that domain to be /e/404. > > That would give the default fedora 404 page, and allow for MultiView to work > > so it will be in the right language. The same will be done for 500. > > > > mmcgrath and I have been talking about this over the last week and a half - > > since the change freeze is extended abit more, I'd like to wrap this up and > > have it in place. > > > > Thoughts? > > > This gets a +1 from me. Getting it on the servers so it has some time for > people to test and report problems before the hard freeze (April 29) is highly > desirable. > Agreed. I'm for this as well. -Mike From mmcgrath at redhat.com Sun Apr 20 17:30:10 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 20 Apr 2008 12:30:10 -0500 (CDT) Subject: Rawhide builds (change) Message-ID: Sorry guys, this one didn't take place on the list I talked to Jesse about it in #fedora-admin. I moved the rawhide build script to about 4 hours earlier. I think its triggering the nfslock outages (and the alerts that follow it) at around 3:30 my time. I figure moving it 4 hours later is nice because when it happens I'll have a better chance of catching steved and a better chance of being alert :) -Mike From jkeating at redhat.com Sun Apr 20 17:45:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Apr 2008 13:45:15 -0400 Subject: Rawhide builds (change) In-Reply-To: References: Message-ID: <1208713515.3445.127.camel@localhost.localdomain> On Sun, 2008-04-20 at 12:30 -0500, Mike McGrath wrote: > I moved the rawhide build script to about 4 hours > earlier. That would be later (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sun Apr 20 20:20:49 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 20 Apr 2008 13:20:49 -0700 Subject: python-fedora upgrade Message-ID: <480BA5A1.40203@gmail.com> Since the release is delayed and we're letting more changes through, I'd like to update to the new python-fedora, 0.2.99.9 that reverts the incompatible changes from 0.2.99.8. I'd like to push this package to all the app servers and fas1 & 2 so that all the major TurboGears apps are on the same version. (We could push to bodhi on releng1 as well if Luke is okay with that.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Sun Apr 20 20:32:36 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 20 Apr 2008 16:32:36 -0400 Subject: python-fedora upgrade In-Reply-To: <480BA5A1.40203@gmail.com> References: <480BA5A1.40203@gmail.com> Message-ID: <20080420203235.GB13566@Max> On 2008-04-20 01:20:49 PM, Toshio Kuratomi wrote: > Since the release is delayed and we're letting more changes through, I'd > like to update to the new python-fedora, 0.2.99.9 that reverts the > incompatible changes from 0.2.99.8. > > I'd like to push this package to all the app servers and fas1 & 2 so that > all the major TurboGears apps are on the same version. (We could push to > bodhi on releng1 as well if Luke is okay with that.) +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ricky at fedoraproject.org Sun Apr 20 21:29:31 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Sun, 20 Apr 2008 17:29:31 -0400 Subject: Change freeze request: Add strace to global packages, gix commit email unicode issue Message-ID: <20080420212931.GA26083@Max> As mentioned on IRC, I'd like to add the strace package to global.pp: Index: manifests/services/global.pp =================================================================== RCS file: /cvs/puppet/manifests/services/global.pp,v retrieving revision 1.79 diff -u -r1.79 global.pp --- manifests/services/global.pp 4 Apr 2008 04:58:33 -0000 1.79 +++ manifests/services/global.pp 19 Apr 2008 22:52:47 -0000 @@ -110,6 +110,9 @@ package { logrotate: ensure => latest } + package { strace: + ensure => latest + } package { logwatch: ensure => absent } Also, I'd like to fix the problem that we've been having with unicode in the from headers of git commit emails. This would involve adding send-unicode-email.py (in http://ricky.fedorapeople.org/fedora-git-commit-mail-hook/) to puppet and modifying git-commit-email-hook to call it instead of sendmail. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Sun Apr 20 21:39:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 20 Apr 2008 14:39:01 -0700 Subject: Change freeze request: Add strace to global packages, gix commit email unicode issue In-Reply-To: <20080420212931.GA26083@Max> References: <20080420212931.GA26083@Max> Message-ID: <480BB7F5.1010307@gmail.com> Ricky Zhou wrote: > As mentioned on IRC, I'd like to add the strace package to global.pp: > > Index: manifests/services/global.pp > =================================================================== > RCS file: /cvs/puppet/manifests/services/global.pp,v > retrieving revision 1.79 > diff -u -r1.79 global.pp > --- manifests/services/global.pp 4 Apr 2008 04:58:33 -0000 > 1.79 > +++ manifests/services/global.pp 19 Apr 2008 22:52:47 -0000 > @@ -110,6 +110,9 @@ > package { logrotate: > ensure => latest > } > + package { strace: > + ensure => latest > + } > package { logwatch: > ensure => absent > } > +1 I find myself needing this all the time. > Also, I'd like to fix the problem that we've been having with unicode in > the from headers of git commit emails. This would involve adding > send-unicode-email.py (in > http://ricky.fedorapeople.org/fedora-git-commit-mail-hook/) to puppet > and modifying git-commit-email-hook to call it instead of sendmail. > +1 Reviewed. Looks good to me. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Sun Apr 20 22:30:14 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 20 Apr 2008 17:30:14 -0500 (CDT) Subject: Rawhide builds (change) In-Reply-To: <1208713515.3445.127.camel@localhost.localdomain> References: <1208713515.3445.127.camel@localhost.localdomain> Message-ID: On Sun, 20 Apr 2008, Jesse Keating wrote: > On Sun, 2008-04-20 at 12:30 -0500, Mike McGrath wrote: > > I moved the rawhide build script to about 4 hours > > earlier. > > That would be later (: > Doah! This warm weather must be going to my head :) -Mike From mmcgrath at redhat.com Sun Apr 20 22:31:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 20 Apr 2008 17:31:23 -0500 (CDT) Subject: python-fedora upgrade In-Reply-To: <20080420203235.GB13566@Max> References: <480BA5A1.40203@gmail.com> <20080420203235.GB13566@Max> Message-ID: On Sun, 20 Apr 2008, Ricky Zhou wrote: > On 2008-04-20 01:20:49 PM, Toshio Kuratomi wrote: > > Since the release is delayed and we're letting more changes through, I'd > > like to update to the new python-fedora, 0.2.99.9 that reverts the > > incompatible changes from 0.2.99.8. > > > > I'd like to push this package to all the app servers and fas1 & 2 so that > > all the major TurboGears apps are on the same version. (We could push to > > bodhi on releng1 as well if Luke is okay with that.) > +1 > +1 -mIKE From mmcgrath at redhat.com Sun Apr 20 22:31:44 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 20 Apr 2008 17:31:44 -0500 (CDT) Subject: Change freeze request: Add strace to global packages, gix commit email unicode issue In-Reply-To: <20080420212931.GA26083@Max> References: <20080420212931.GA26083@Max> Message-ID: On Sun, 20 Apr 2008, Ricky Zhou wrote: > As mentioned on IRC, I'd like to add the strace package to global.pp: > > Index: manifests/services/global.pp > =================================================================== > RCS file: /cvs/puppet/manifests/services/global.pp,v > retrieving revision 1.79 > diff -u -r1.79 global.pp > --- manifests/services/global.pp 4 Apr 2008 04:58:33 -0000 > 1.79 > +++ manifests/services/global.pp 19 Apr 2008 22:52:47 -0000 > @@ -110,6 +110,9 @@ > package { logrotate: > ensure => latest > } > + package { strace: > + ensure => latest > + } > package { logwatch: > ensure => absent > } > > Also, I'd like to fix the problem that we've been having with unicode in > the from headers of git commit emails. This would involve adding > send-unicode-email.py (in > http://ricky.fedorapeople.org/fedora-git-commit-mail-hook/) to puppet > and modifying git-commit-email-hook to call it instead of sendmail. > +1 -Mike From lmacken at redhat.com Sun Apr 20 23:19:35 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 20 Apr 2008 19:19:35 -0400 Subject: python-fedora upgrade In-Reply-To: <480BA5A1.40203@gmail.com> References: <480BA5A1.40203@gmail.com> Message-ID: <20080420231935.GD5008@crow> On Sun, Apr 20, 2008 at 01:20:49PM -0700, Toshio Kuratomi wrote: > Since the release is delayed and we're letting more changes through, I'd > like to update to the new python-fedora, 0.2.99.9 that reverts the > incompatible changes from 0.2.99.8. > > I'd like to push this package to all the app servers and fas1 & 2 so that > all the major TurboGears apps are on the same version. (We could push to > bodhi on releng1 as well if Luke is okay with that.) That's fine with me. luke From jkeating at redhat.com Mon Apr 21 13:56:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 09:56:55 -0400 Subject: CVS Outage In-Reply-To: <1208631941.3445.88.camel@localhost.localdomain> References: <1208631941.3445.88.camel@localhost.localdomain> Message-ID: <1208786215.3258.7.camel@localhost.localdomain> On Sat, 2008-04-19 at 15:05 -0400, Jesse Keating wrote: > > There will be an outage starting at 2008-04-19 18:00 UTC. Initial > estimates show that 30 hours will be needed to complete the branching, > however this may drastically be reduced during the full run. Unfortunately this outage is still ongoing. I failed to get a notification when the first leg finished around 2am my time and lost 6~ hours to sleep. All the PackageDB settings are done (barring a few failures) and we're well into the packages that start with "p" for making the branches within CVS. I expect it to take another half a day or so to finish. Future Recommendation: Enable methods of doing mass branching without incurring an outage. Make pkgdb be able to bypass mail sending, and make CVS be able to bypass mail sending for these operations. Will take longer overall, but no outage. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Mon Apr 21 14:04:35 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 09:04:35 -0500 (CDT) Subject: change request (/mnt/koji fs issues) Message-ID: So we're in a bit of trouble. Right now the ext3 filesystem on /mnt/koji is in a sort of funky state. There's a section of the filesystem that is pretty borked. Running fsck.ext3 on it causes a segfault. The core dump is 2G right now. This is likely from the short few hours we ran /mnt/koji from a RHEL4 box (lesson learned there...) Steps to proceed: 1) Snapshots - I've been doing all of my tests from snapshots and will continue to do so. The share itself doesn't seem to be catastrophically broken, just that one section. 2) Contact some fs experts with the dump and see what is going on. 3) Fix the filesystem. 4) Also, for the last 4 nights at around 3 am my time the filesystem has hit this part of the disk causing it to get remounted ro. I'd like to setup a script to auto correct this issue until we can come up with a permanent fix. Just saves me from having to get up in the middle of the night. Is anyone against this? I'm mostly worried about step3 then anything. Before we do that I want to make sure we have a proper backup and do plenty of tests from snapshots. It might be best to do 3) after the release. -Mike From jkeating at redhat.com Mon Apr 21 14:07:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 10:07:46 -0400 Subject: change request (/mnt/koji fs issues) In-Reply-To: References: Message-ID: <1208786866.3258.10.camel@localhost.localdomain> On Mon, 2008-04-21 at 09:04 -0500, Mike McGrath wrote: > So we're in a bit of trouble. Right now the ext3 filesystem on /mnt/koji > is in a sort of funky state. There's a section of the filesystem that is > pretty borked. Running fsck.ext3 on it causes a segfault. The core dump > is 2G right now. This is likely from the short few hours we ran /mnt/koji > from a RHEL4 box (lesson learned there...) > > Steps to proceed: > > 1) Snapshots - I've been doing all of my tests from snapshots and will > continue to do so. The share itself doesn't seem to be catastrophically > broken, just that one section. > > 2) Contact some fs experts with the dump and see what is going on. > > 3) Fix the filesystem. > > 4) Also, for the last 4 nights at around 3 am my time the filesystem has > hit this part of the disk causing it to get remounted ro. I'd like to > setup a script to auto correct this issue until we can come up with a > permanent fix. Just saves me from having to get up in the middle of the > night. > > Is anyone against this? I'm mostly worried about step3 then anything. > Before we do that I want to make sure we have a proper backup and do > plenty of tests from snapshots. It might be best to do 3) after the > release. > This gets a +1 from me. Must keep that thing stable, and you sane. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Mon Apr 21 15:51:23 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 21 Apr 2008 09:51:23 -0600 Subject: change request (/mnt/koji fs issues) In-Reply-To: <1208786866.3258.10.camel@localhost.localdomain> References: <1208786866.3258.10.camel@localhost.localdomain> Message-ID: <80d7e4090804210851s1a8f21a2w95ed215c6f0e4c9c@mail.gmail.com> 2008/4/21 Jesse Keating : > On Mon, 2008-04-21 at 09:04 -0500, Mike McGrath wrote: > > So we're in a bit of trouble. Right now the ext3 filesystem on /mnt/koji > > is in a sort of funky state. There's a section of the filesystem that is > > pretty borked. Running fsck.ext3 on it causes a segfault. The core dump > > is 2G right now. This is likely from the short few hours we ran /mnt/koji > > from a RHEL4 box (lesson learned there...) > > > > Steps to proceed: > > > > 1) Snapshots - I've been doing all of my tests from snapshots and will > > continue to do so. The share itself doesn't seem to be catastrophically > > broken, just that one section. > > > > 2) Contact some fs experts with the dump and see what is going on. > > > > 3) Fix the filesystem. > > > > 4) Also, for the last 4 nights at around 3 am my time the filesystem has > > hit this part of the disk causing it to get remounted ro. I'd like to > > setup a script to auto correct this issue until we can come up with a > > permanent fix. Just saves me from having to get up in the middle of the > > night. > > > > Is anyone against this? I'm mostly worried about step3 then anything. > > Before we do that I want to make sure we have a proper backup and do > > plenty of tests from snapshots. It might be best to do 3) after the > > release. > > > > This gets a +1 from me. Must keep that thing stable, and you sane. > Ah but Mike has viewed the depths of filesystem creation and seen the dark Lords who live there dancing forever around the sleeping Nameless One. Its too late.. the best we can do is wall him up in a room next to Seth and Stephen Tweedie and let them chant their prayers to their new Mad Overlords: "Ph'sck mount'slafh Extphree" though Seth's is more "O'yum rp'm" but they do go together as harmony. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Mon Apr 21 16:02:00 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 21 Apr 2008 12:02:00 -0400 Subject: change request (/mnt/koji fs issues) In-Reply-To: <80d7e4090804210851s1a8f21a2w95ed215c6f0e4c9c@mail.gmail.com> References: <1208786866.3258.10.camel@localhost.localdomain> <80d7e4090804210851s1a8f21a2w95ed215c6f0e4c9c@mail.gmail.com> Message-ID: <1208793720.30546.37.camel@cutter> On Mon, 2008-04-21 at 09:51 -0600, Stephen John Smoogen wrote: > Ah but Mike has viewed the depths of filesystem creation and seen the > dark Lords who live there dancing forever around the sleeping Nameless > One. Its too late.. the best we can do is wall him up in a room next > to Seth and Stephen Tweedie and let them chant their prayers to their > new Mad Overlords: "Ph'sck mount'slafh Extphree" though Seth's is more > "O'yum rp'm" but they do go together as harmony. Stephen, The pills you're taking today are clearly just placebos. Tell the doctors you'd like the 'good stuff' from now on. okay? :) -sv From smooge at gmail.com Mon Apr 21 16:13:37 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 21 Apr 2008 10:13:37 -0600 Subject: change request (/mnt/koji fs issues) In-Reply-To: <1208793720.30546.37.camel@cutter> References: <1208786866.3258.10.camel@localhost.localdomain> <80d7e4090804210851s1a8f21a2w95ed215c6f0e4c9c@mail.gmail.com> <1208793720.30546.37.camel@cutter> Message-ID: <80d7e4090804210913q3d6b212nc87930719a3c529c@mail.gmail.com> On Mon, Apr 21, 2008 at 10:02 AM, seth vidal wrote: > On Mon, 2008-04-21 at 09:51 -0600, Stephen John Smoogen wrote: > > > Ah but Mike has viewed the depths of filesystem creation and seen the > > dark Lords who live there dancing forever around the sleeping Nameless > > One. Its too late.. the best we can do is wall him up in a room next > > to Seth and Stephen Tweedie and let them chant their prayers to their > > new Mad Overlords: "Ph'sck mount'slafh Extphree" though Seth's is more > > "O'yum rp'm" but they do go together as harmony. > > Stephen, > The pills you're taking today are clearly just placebos. Tell the > doctors you'd like the 'good stuff' from now on. okay? :) > Oh I am not falling for that trick again.. You said last week to tell them to up the voltage.. haha very funny that hurt. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mmcgrath at redhat.com Mon Apr 21 19:10:45 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 14:10:45 -0500 (CDT) Subject: xen and tcp checksumming Message-ID: We continue to have sporatic tcp checksum issues in xen (known issue in xen, I think its even in their FAQ) I'd like to disable the hardware checksumming: ethtool -K eth0 tx off in rc.local. Its not actively causing issues but it is causing inefficient transfers in some cases. I'd like to do this before the freeze. Anyone have any problems with that? -Mike From mmcgrath at redhat.com Mon Apr 21 19:17:53 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 14:17:53 -0500 (CDT) Subject: Change Request (app5) In-Reply-To: <480914D7.6060801@gmail.com> References: <480914D7.6060801@gmail.com> Message-ID: On Fri, 18 Apr 2008, Toshio Kuratomi wrote: > Mike McGrath wrote: > > I'd like to spend the rest of our non firm change window to try to get > > app5 in order. If I'm unable I'd like to revert it to the x86_64 image > > (still on the box) until after the release. > > > +1. > > When would be the drop dead date to revert? Friday before the hard freeze? > The friday before the hard freeze. Side note about this, the change I have to make now may have an impact on more then just app5. I'd like to change the kernel on the dom0 to one closer to what will ship with RHEL5.2. This will affect: app5, noc2, proxy3, publictest10, publictest12. We can do this without any actual downtime to our end users. -Mike From a.badger at gmail.com Mon Apr 21 19:22:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Apr 2008 12:22:06 -0700 Subject: xen and tcp checksumming In-Reply-To: References: Message-ID: <480CE95E.3060306@gmail.com> Mike McGrath wrote: > We continue to have sporatic tcp checksum issues in xen (known issue in > xen, I think its even in their FAQ) > > I'd like to disable the hardware checksumming: > > ethtool -K eth0 tx off > > in rc.local. Its not actively causing issues but it is causing > inefficient transfers in some cases. I'd like to do this before the > freeze. Anyone have any problems with that? > +1. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Mon Apr 21 19:26:38 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 21 Apr 2008 15:26:38 -0400 Subject: Change Request (app5) In-Reply-To: References: <480914D7.6060801@gmail.com> Message-ID: <1208805998.3712.16.camel@cutter> On Mon, 2008-04-21 at 14:17 -0500, Mike McGrath wrote: > On Fri, 18 Apr 2008, Toshio Kuratomi wrote: > > > Mike McGrath wrote: > > > I'd like to spend the rest of our non firm change window to try to get > > > app5 in order. If I'm unable I'd like to revert it to the x86_64 image > > > (still on the box) until after the release. > > > > > +1. > > > > When would be the drop dead date to revert? Friday before the hard freeze? > > > > The friday before the hard freeze. > > Side note about this, the change I have to make now may have an impact on > more then just app5. I'd like to change the kernel on the dom0 to one > closer to what will ship with RHEL5.2. This will affect: > > app5, noc2, proxy3, publictest10, publictest12. > > We can do this without any actual downtime to our end users. > +1 - anything to make it less crash-y thanks, -sv From a.badger at gmail.com Mon Apr 21 19:29:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Apr 2008 12:29:25 -0700 Subject: Change Request (app5) In-Reply-To: References: <480914D7.6060801@gmail.com> Message-ID: <480CEB15.10008@gmail.com> Mike McGrath wrote: > On Fri, 18 Apr 2008, Toshio Kuratomi wrote: > >> Mike McGrath wrote: >>> I'd like to spend the rest of our non firm change window to try to get >>> app5 in order. If I'm unable I'd like to revert it to the x86_64 image >>> (still on the box) until after the release. >>> >> +1. >> >> When would be the drop dead date to revert? Friday before the hard freeze? >> > > The friday before the hard freeze. > > Side note about this, the change I have to make now may have an impact on > more then just app5. I'd like to change the kernel on the dom0 to one > closer to what will ship with RHEL5.2. This will affect: > > app5, noc2, proxy3, publictest10, publictest12. > > We can do this without any actual downtime to our end users. > +1. Just let J5 know before you do it as he's using publictest10. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Mon Apr 21 19:29:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 15:29:54 -0400 Subject: xen and tcp checksumming In-Reply-To: References: Message-ID: <1208806194.3258.68.camel@localhost.localdomain> On Mon, 2008-04-21 at 14:10 -0500, Mike McGrath wrote: > We continue to have sporatic tcp checksum issues in xen (known issue in > xen, I think its even in their FAQ) > > I'd like to disable the hardware checksumming: > > ethtool -K eth0 tx off > > in rc.local. Its not actively causing issues but it is causing > inefficient transfers in some cases. I'd like to do this before the > freeze. Anyone have any problems with that? > Make it so. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Apr 21 20:49:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 16:49:52 -0400 Subject: Change: Disable koji garbage collection scripts that touch the filesystem Message-ID: <1208810992.3258.78.camel@localhost.localdomain> This was discussed on IRC, we're disabling the garbage collection scripts which we think are causing the filesystem to remount ro. The delete part of koji-gc, the koji-prunesigs, and the koji-directory-cleanup have all been disabled in puppet. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Mon Apr 21 20:52:19 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 15:52:19 -0500 (CDT) Subject: German Colo test server In-Reply-To: <20080419170032.GA14422@Max> References: <20080419170032.GA14422@Max> Message-ID: On Sat, 19 Apr 2008, Ricky Zhou wrote: > On 2008-04-19 11:27:40 AM, Mike McGrath wrote: > > I'd like to get another test server up in the new datacenter for Frank et > > all to work on the wordpress deployment. This should have _no_ affect on > > anything but its a change in the freeze. Rules are rules :) > +1 > This is done, publictest13 is online. -Mike From mmcgrath at redhat.com Mon Apr 21 20:55:29 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 15:55:29 -0500 (CDT) Subject: Change Request (app5) In-Reply-To: <480CEB15.10008@gmail.com> References: <480914D7.6060801@gmail.com> <480CEB15.10008@gmail.com> Message-ID: On Mon, 21 Apr 2008, Toshio Kuratomi wrote: > Mike McGrath wrote: > > On Fri, 18 Apr 2008, Toshio Kuratomi wrote: > > > > > Mike McGrath wrote: > > > > I'd like to spend the rest of our non firm change window to try to get > > > > app5 in order. If I'm unable I'd like to revert it to the x86_64 image > > > > (still on the box) until after the release. > > > > > > > +1. > > > > > > When would be the drop dead date to revert? Friday before the hard > > > freeze? > > > > > > > The friday before the hard freeze. > > > > Side note about this, the change I have to make now may have an impact on > > more then just app5. I'd like to change the kernel on the dom0 to one > > closer to what will ship with RHEL5.2. This will affect: > > > > app5, noc2, proxy3, publictest10, publictest12. > > > > We can do this without any actual downtime to our end users. > > > +1. > > Just let J5 know before you do it as he's using publictest10. > Crap, sorry J5. Needless to say this is done. We'll know in a few hours if its made a difference. -Mike From a.badger at gmail.com Mon Apr 21 22:12:01 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Apr 2008 15:12:01 -0700 Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes Message-ID: <480D1131.8030804@gmail.com> The Bugzilla sync scripts are currently running on a RHEL4 machine on Jeremy's desk. There are a few problems with them that would be hard to fix without RHEL 5. Since it would be helpful to move this out to a Fedora box anyway so anyone can modify them, I'd like to move them to the app servers. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Mon Apr 21 22:20:56 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Mon, 21 Apr 2008 18:20:56 -0400 Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes In-Reply-To: <480D1131.8030804@gmail.com> References: <480D1131.8030804@gmail.com> Message-ID: <20080421222056.GA11282@Max> On 2008-04-21 03:12:01 PM, Toshio Kuratomi wrote: > The Bugzilla sync scripts are currently running on a RHEL4 machine on > Jeremy's desk. There are a few problems with them that would be hard to > fix without RHEL 5. Since it would be helpful to move this out to a Fedora > box anyway so anyone can modify them, I'd like to move them to the app > servers. +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Mon Apr 21 22:24:12 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Apr 2008 18:24:12 -0400 Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes In-Reply-To: <480D1131.8030804@gmail.com> References: <480D1131.8030804@gmail.com> Message-ID: <20080421222412.GA12859@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > The Bugzilla sync scripts are currently running on a RHEL4 machine on > Jeremy's desk. There are a few problems with them that would be hard to > fix without RHEL 5. Since it would be helpful to move this out to a Fedora > box anyway so anyone can modify them, I'd like to move them to the app > servers. As long as there are no weird firewall/xmlrpc issues causing them to need to be 'inside', go for it. Bill From mmcgrath at redhat.com Tue Apr 22 01:40:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 20:40:46 -0500 (CDT) Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes In-Reply-To: <480D1131.8030804@gmail.com> References: <480D1131.8030804@gmail.com> Message-ID: On Mon, 21 Apr 2008, Toshio Kuratomi wrote: > The Bugzilla sync scripts are currently running on a RHEL4 machine on Jeremy's > desk. There are a few problems with them that would be hard to fix without > RHEL 5. Since it would be helpful to move this out to a Fedora box anyway so > anyone can modify them, I'd like to move them to the app servers. > I'm fine with this, do those scripts make changes to the database directly or via bugzilla? If its viabugzilla we should probably put them on a machine that is not in phx. -Mike From a.badger at gmail.com Tue Apr 22 01:56:50 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Apr 2008 18:56:50 -0700 Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes In-Reply-To: References: <480D1131.8030804@gmail.com> Message-ID: <480D45E2.2010501@gmail.com> Mike McGrath wrote: > On Mon, 21 Apr 2008, Toshio Kuratomi wrote: > >> The Bugzilla sync scripts are currently running on a RHEL4 machine on Jeremy's >> desk. There are a few problems with them that would be hard to fix without >> RHEL 5. Since it would be helpful to move this out to a Fedora box anyway so >> anyone can modify them, I'd like to move them to the app servers. >> > > I'm fine with this, do those scripts make changes to the database directly > or via bugzilla? If its viabugzilla we should probably put them on a > machine that is not in phx. > Via bugzilla xmlrpc. The special phx address works inside of phx and bugzilla.redhat.com works outside of it. Now that app5 is stable (Over an hour, woo hoo!) I can set them up in puppet to run from there. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Tue Apr 22 02:26:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 Apr 2008 21:26:51 -0500 (CDT) Subject: Change Request: Moving bugzilla sync scripts onto Fedora Boxes In-Reply-To: <480D45E2.2010501@gmail.com> References: <480D1131.8030804@gmail.com> <480D45E2.2010501@gmail.com> Message-ID: On Mon, 21 Apr 2008, Toshio Kuratomi wrote: > Mike McGrath wrote: > > On Mon, 21 Apr 2008, Toshio Kuratomi wrote: > > > > > The Bugzilla sync scripts are currently running on a RHEL4 machine on > > > Jeremy's > > > desk. There are a few problems with them that would be hard to fix > > > without > > > RHEL 5. Since it would be helpful to move this out to a Fedora box anyway > > > so > > > anyone can modify them, I'd like to move them to the app servers. > > > > > > > I'm fine with this, do those scripts make changes to the database directly > > or via bugzilla? If its viabugzilla we should probably put them on a > > machine that is not in phx. > > > Via bugzilla xmlrpc. The special phx address works inside of phx and > bugzilla.redhat.com works outside of it. Now that app5 is stable (Over an > hour, woo hoo!) I can set them up in puppet to run from there. > I'd prefer to stick with bugzilla.redhat.com, I'm not sure what the deal is with the special address other then it works today, I don't think its technically a supported service so much as "thats the way its currently setup" so its probably best to avoid it if we can. -Mike From mmcgrath at redhat.com Tue Apr 22 14:16:45 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 09:16:45 -0500 (CDT) Subject: cvs space Message-ID: So our cvs storage space is filling up (currently at 80% free) that should last us a while. The plan for a while (not that I'd shared it) had been to move the lookaside cache to the netapp. It really doesn't get heavy load and is the majority of that 80%. We've still got some time before that fills up so this will be a post F9 thing easy. Probably after the new wiki gets deployed. Does anyone have a problem or see a problem with moving the lookaside cache to nfs? -Mike From jonstanley at gmail.com Tue Apr 22 15:01:31 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 22 Apr 2008 11:01:31 -0400 Subject: cvs space In-Reply-To: References: Message-ID: On Tue, Apr 22, 2008 at 10:16 AM, Mike McGrath wrote: > So our cvs storage space is filling up (currently at 80% free) Is that supposed to be 80% used? :) From mmcgrath at redhat.com Tue Apr 22 15:06:50 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 10:06:50 -0500 (CDT) Subject: cvs space In-Reply-To: References: Message-ID: On Tue, 22 Apr 2008, Jon Stanley wrote: > On Tue, Apr 22, 2008 at 10:16 AM, Mike McGrath wrote: > > So our cvs storage space is filling up (currently at 80% free) > > Is that supposed to be 80% used? :) > yes it is. -Mike From jkeating at redhat.com Tue Apr 22 15:25:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Apr 2008 11:25:31 -0400 Subject: CVS Outage Complete In-Reply-To: <1208786215.3258.7.camel@localhost.localdomain> References: <1208631941.3445.88.camel@localhost.localdomain> <1208786215.3258.7.camel@localhost.localdomain> Message-ID: <1208877931.3258.106.camel@localhost.localdomain> On Mon, 2008-04-21 at 09:56 -0400, Jesse Keating wrote: > On Sat, 2008-04-19 at 15:05 -0400, Jesse Keating wrote: > > > > There will be an outage starting at 2008-04-19 18:00 UTC. Initial > > estimates show that 30 hours will be needed to complete the branching, > > however this may drastically be reduced during the full run. > > Unfortunately this outage is still ongoing. I failed to get a > notification when the first leg finished around 2am my time and lost 6~ > hours to sleep. All the PackageDB settings are done (barring a few > failures) and we're well into the packages that start with "p" for > making the branches within CVS. I expect it to take another half a day > or so to finish. > > Future Recommendation: > Enable methods of doing mass branching without incurring an outage. > Make pkgdb be able to bypass mail sending, and make CVS be able to > bypass mail sending for these operations. Will take longer overall, but > no outage. > The marathon outage is finally over. This should be the last outage we ever do for CVS branching. One thing that has changed is you can no longer checkout fake branch trees like "cvs co cvs/pkgs/F-7". Those modules have been disabled due to limited usefulness, frequent breakage, and rather time consuming setup in the modules file. Nor can you checkout a package branch only, such as bash-F-7. On the plus side it makes branching significantly faster and new package creation significantly faster. PackageDB will be enabled again in the next few minutes, and the ACL script will run again too. Please let us know if you experience any difficulties or seem to be missing an F-9 branch. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Tue Apr 22 15:27:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 10:27:51 -0500 (CDT) Subject: app3 rebuild (change request) Message-ID: Well since we've got the time I'd like to rebuild app3. its the last of our FC6 boxes. This is a low risk operation since we're not really using app3 for much now anyway (only the smolt wiki). Plus it'll be a: 1) build new app3 2) verify it works 3) destroy old app3 -Mike From jkeating at redhat.com Tue Apr 22 15:32:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Apr 2008 11:32:03 -0400 Subject: app3 rebuild (change request) In-Reply-To: References: Message-ID: <1208878323.3258.110.camel@localhost.localdomain> On Tue, 2008-04-22 at 10:27 -0500, Mike McGrath wrote: > Well since we've got the time I'd like to rebuild app3. its the last of > our FC6 boxes. This is a low risk operation since we're not really using > app3 for much now anyway (only the smolt wiki). Plus it'll be a: > > 1) build new app3 > 2) verify it works > 3) destroy old app3 > > -Mike +1 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Tue Apr 22 16:15:25 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 22 Apr 2008 12:15:25 -0400 Subject: cvs space In-Reply-To: References: Message-ID: <1208880925.12246.2.camel@aglarond.local> On Tue, 2008-04-22 at 09:16 -0500, Mike McGrath wrote: > So our cvs storage space is filling up (currently at 80% free) that > should last us a while. The plan for a while (not that I'd shared it) had > been to move the lookaside cache to the netapp. It really doesn't get > heavy load and is the majority of that 80%. We've still got some time > before that fills up so this will be a post F9 thing easy. Probably after > the new wiki gets deployed. > > Does anyone have a problem or see a problem with moving the lookaside > cache to nfs? Seems fine to me. Jeremy From a.badger at gmail.com Tue Apr 22 16:13:00 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 22 Apr 2008 09:13:00 -0700 Subject: app3 rebuild (change request) In-Reply-To: References: Message-ID: <480E0E8C.2050107@gmail.com> Mike McGrath wrote: > Well since we've got the time I'd like to rebuild app3. its the last of > our FC6 boxes. This is a low risk operation since we're not really using > app3 for much now anyway (only the smolt wiki). Plus it'll be a: > > 1) build new app3 > 2) verify it works > 3) destroy old app3 > +1. No sense letting the current app3 sit around doing very little work. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Tue Apr 22 16:24:35 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 11:24:35 -0500 (CDT) Subject: Outage 5/3 Message-ID: There will be a network outage on 5/3. This is just a heads up, the official outage notification with more details will come up when I get them. Looks like network work by the soc. -Mike From mgalgoci at redhat.com Tue Apr 22 16:38:16 2008 From: mgalgoci at redhat.com (Matthew Galgoci) Date: Tue, 22 Apr 2008 12:38:16 -0400 Subject: Outage 5/3 In-Reply-To: References: Message-ID: > Date: Tue, 22 Apr 2008 11:24:35 -0500 (CDT) > From: Mike McGrath > Reply-To: fedora-infrastructure-list at redhat.com > To: fedora-infrastructure-list at redhat.com > Subject: Outage 5/3 > > There will be a network outage on 5/3. This is just a heads up, the > official outage notification with more details will come up when I get > them. Looks like network work by the soc. No it's network work done by noc :P -- Matthew Galgoci Network Operations Red Hat, Inc 919.754.3700 x44155 From ricky at fedoraproject.org Tue Apr 22 18:13:10 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Tue, 22 Apr 2008 14:13:10 -0400 Subject: app3 rebuild (change request) In-Reply-To: References: Message-ID: <20080422181310.GB24880@Max> On 2008-04-22 10:27:51 AM, Mike McGrath wrote: > Well since we've got the time I'd like to rebuild app3. its the last of > our FC6 boxes. This is a low risk operation since we're not really using > app3 for much now anyway (only the smolt wiki). Plus it'll be a: > > 1) build new app3 > 2) verify it works > 3) destroy old app3 +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Tue Apr 22 19:54:17 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 14:54:17 -0500 (CDT) Subject: Outage Notification - 2008-05-08 14:00 UTC Message-ID: There will be an outage starting at 2008-05-08 14:00 UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-05-08 14:00 UTC' Affected Services: Websites CVS / Source Control Buildsystem Database Mail All auth systems Unaffected Services: Torrent DNS fedorapeople.org planet Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/519 Reason for Outage: The network guys will be performing a number of upgrades during this outage window which is expected to last 5 hours. Systems will be up and down during this time. Some will be off during the duration of the time for safety / data protection. Some systems we'll be moving to alternate sites. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From mmcgrath at redhat.com Tue Apr 22 19:59:36 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 14:59:36 -0500 (CDT) Subject: Outage Notification - 2008-05-08 14:00 UTC In-Reply-To: References: Message-ID: Alright guys, so this is going to be a pretty big deal. We'll have to shut off some services completely (especially iscsi) during this time. Some services, like the website and mirrors list, we can just switch to alternate sites. Also stuff that attaches over nfs we can probably safely leave up (for example... infrastructure.fedoraproject.org) it'll drop when they kill the connection, and come back up on its own. -Mike On Tue, 22 Apr 2008, Mike McGrath wrote: > There will be an outage starting at 2008-05-08 14:00 UTC, which will last > approximately 5 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2008-05-08 14:00 UTC' > > Affected Services: > > Websites > CVS / Source Control > Buildsystem > Database > Mail > All auth systems > > Unaffected Services: > Torrent > DNS > fedorapeople.org > planet > > Ticket Link: > > https://fedorahosted.org/fedora-infrastructure/ticket/519 > > Reason for Outage: > > The network guys will be performing a number of upgrades during this > outage window which is expected to last 5 hours. Systems will be up and > down during this time. Some will be off during the duration of the time > for safety / data protection. Some systems we'll be moving to alternate > sites. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to > track the status of this outage. > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From mmcgrath at redhat.com Tue Apr 22 20:10:16 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Apr 2008 15:10:16 -0500 (CDT) Subject: Outage Notification - 2008-05-03 14:00 UTC (fwd) Message-ID: Sorry everyone, the previous message had the wrong date. The correct date is: 2008-05-03 14:00 UTC ---------- Forwarded message ---------- Date: Tue, 22 Apr 2008 14:54:17 -0500 (CDT) From: Mike McGrath To: fedora-devel-announce at redhat.com Cc: fedora-infrastructure-list at redhat.com, fedora-docs-list at redhat.com, Fedora Art List , For discussions about marketing and expanding the Fedora user base , fedora-websites-list at redhat.com Subject: Outage Notification - 2008-05-03 14:00 UTC There will be an outage starting at 2008-05-03 14:00 UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-05-03 14:00 UTC' Affected Services: Websites CVS / Source Control Buildsystem Database Mail All auth systems Unaffected Services: Torrent DNS fedorapeople.org planet Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/519 Reason for Outage: The network guys will be performing a number of upgrades during this outage window which is expected to last 5 hours. Systems will be up and down during this time. Some will be off during the duration of the time for safety / data protection. Some systems we'll be moving to alternate sites. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From mmcgrath at redhat.com Wed Apr 23 13:22:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 08:22:31 -0500 (CDT) Subject: Change Request for identity team Message-ID: I'd like to add the following lines to fedorahosted. The identity team would like to access their repos again: DAV svn SVNParentPath /svn/identity Options Indexes -Mike From skvidal at fedoraproject.org Wed Apr 23 13:29:14 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Apr 2008 09:29:14 -0400 Subject: Change Request for identity team In-Reply-To: References: Message-ID: <1208957354.3712.73.camel@cutter> On Wed, 2008-04-23 at 08:22 -0500, Mike McGrath wrote: > I'd like to add the following lines to fedorahosted. The identity team > would like to access their repos again: > > > DAV svn > SVNParentPath /svn/identity > > > Options Indexes > > +1 any fedorahosted issues won't kill us for the release anyway -sv From mmcgrath at redhat.com Wed Apr 23 14:01:04 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 09:01:04 -0500 (CDT) Subject: Change Request (Koji pkg server) Message-ID: We've talked about it forever, I'd like to get the pkg server up and going. its purpose is just to serve http files to the builders and public via koji's share. -Mike From dev at nigelj.com Wed Apr 23 14:06:43 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 24 Apr 2008 02:06:43 +1200 (NZST) Subject: Change Request (Koji pkg server) In-Reply-To: References: Message-ID: <53191.202.154.156.240.1208959603.squirrel@webmail.nigelj.com> > We've talked about it forever, I'd like to get the pkg server up and > going. its purpose is just to serve http files to the builders and public > via koji's share. +1, agree 100% Can we also have an email send to f-d-announce explaining the build failures too (esp now we know that we are fixing it). > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From skvidal at fedoraproject.org Wed Apr 23 14:19:14 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Apr 2008 10:19:14 -0400 Subject: change request - add addresses to press@ alias Message-ID: <1208960354.3712.83.camel@cutter> Hey, Max asked if I could add someone to the press@ alias for fp.o - any objections? This is pretty low-impact, I think. -sv -- I only speak for me. From mmcgrath at redhat.com Wed Apr 23 14:21:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 09:21:25 -0500 (CDT) Subject: change request - add addresses to press@ alias In-Reply-To: <1208960354.3712.83.camel@cutter> References: <1208960354.3712.83.camel@cutter> Message-ID: On Wed, 23 Apr 2008, seth vidal wrote: > Hey, > Max asked if I could add someone to the press@ alias for fp.o - any > objections? This is pretty low-impact, I think. > +1 > > -- > I only speak for me. > I also speak for seth. -Mike From mmcgrath at redhat.com Wed Apr 23 15:17:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 10:17:22 -0500 (CDT) Subject: app3 rebuild (change request) In-Reply-To: <20080422181310.GB24880@Max> References: <20080422181310.GB24880@Max> Message-ID: On Tue, 22 Apr 2008, Ricky Zhou wrote: > On 2008-04-22 10:27:51 AM, Mike McGrath wrote: > > Well since we've got the time I'd like to rebuild app3. its the last of > > our FC6 boxes. This is a low risk operation since we're not really using > > app3 for much now anyway (only the smolt wiki). Plus it'll be a: > > > > 1) build new app3 > > 2) verify it works > > 3) destroy old app3 > +1 > Ok, the new app3 is up and running, please keep an eye on our apps (mirrormanger, mirror list, smolt, pkgdb) -Mike From a.badger at gmail.com Thu Apr 24 01:02:44 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Apr 2008 18:02:44 -0700 Subject: Change Request: Even newer python-fedora Message-ID: <480FDC34.6060101@gmail.com> In testing the bugzilla sync scripts on Fedora Servers I found a few bugs in python-fedora's bugzilla handling (one's an update of the user to bugzilla email mapping. The other is returning bugzilla email addresses from one piece of the API.) I need to get a new python-fedora on the app servers to address these issues. Patch with the proposed code changes is attached. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: python-fedora-bugzilla.patch Type: text/x-patch Size: 1575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dev at nigelj.com Thu Apr 24 01:09:48 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 24 Apr 2008 13:09:48 +1200 (NZST) Subject: Change Request: Even newer python-fedora In-Reply-To: <480FDC34.6060101@gmail.com> References: <480FDC34.6060101@gmail.com> Message-ID: <55607.202.154.156.240.1208999388.squirrel@webmail.nigelj.com> > In testing the bugzilla sync scripts on Fedora Servers I found a few > bugs in python-fedora's bugzilla handling (one's an update of the user > to bugzilla email mapping. The other is returning bugzilla email > addresses from one piece of the API.) > > I need to get a new python-fedora on the app servers to address these > issues. Patch with the proposed code changes is attached. Patch looks good, +1 > -Toshio > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From Matt_Domsch at dell.com Thu Apr 24 01:14:55 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 23 Apr 2008 20:14:55 -0500 Subject: app6 up Message-ID: <20080424011455.GG12908@auslistsprd01.us.dell.com> so I'm a little late requesting permission, though I was on IRC during the whole "ordeal" :-) so plenty of people had a chance to object. I brought up app6 as a xen guest on telia1.fp.o in Germany. It's only running MM's mirrorlist server right now, but all seems fine and dandy. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From a.badger at gmail.com Thu Apr 24 02:04:35 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Apr 2008 19:04:35 -0700 Subject: app6 up In-Reply-To: <20080424011455.GG12908@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> Message-ID: <480FEAB3.4060900@gmail.com> Matt Domsch wrote: > so I'm a little late requesting permission, though I was on IRC during > the whole "ordeal" :-) so plenty of people had a chance to object. I > brought up app6 as a xen guest on telia1.fp.o in Germany. It's only > running MM's mirrorlist server right now, but all seems fine and > dandy. > That's excellent. I wonder what the latency for requests is from app6.... (Could make some of the things that J5 is trying to do with myfedora even harder.) Of course, we don't have to run apps that myfedora consumes on app6 but it would be nice to not have to worry about physical geography when an emergency causes us to need to bring up other applications on a different app server. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Matt_Domsch at dell.com Thu Apr 24 02:12:19 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 23 Apr 2008 21:12:19 -0500 Subject: app6 up In-Reply-To: <480FEAB3.4060900@gmail.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> Message-ID: <20080424021219.GB5316@auslistsprd01.us.dell.com> On Wed, Apr 23, 2008 at 07:04:35PM -0700, Toshio Kuratomi wrote: > Matt Domsch wrote: > >so I'm a little late requesting permission, though I was on IRC during > >the whole "ordeal" :-) so plenty of people had a chance to object. I > >brought up app6 as a xen guest on telia1.fp.o in Germany. It's only > >running MM's mirrorlist server right now, but all seems fine and > >dandy. > > > That's excellent. I wonder what the latency for requests is from > app6.... (Could make some of the things that J5 is trying to do with > myfedora even harder.) > > Of course, we don't have to run apps that myfedora consumes on app6 but > it would be nice to not have to worry about physical geography when an > emergency causes us to need to bring up other applications on a > different app server. For those of us in the US, yes, it's higher. From Europe I suspect it's faster for them than it is for us. Typical responses when hitting app3 and app5 are in the 0.300-0.400s range. When hitting app6 I'm seeing around 0.800s. It's a shame mod_proxy_balancer doesn't grok geoip. It'd be fun for it to default North American users to our US app servers, .EU to Telia, with the fallback to use any of the others that are alive... Anyone up for some coding? :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Thu Apr 24 02:12:25 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 21:12:25 -0500 (CDT) Subject: app6 up In-Reply-To: <20080424021219.GB5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> Message-ID: On Wed, 23 Apr 2008, Matt Domsch wrote: > On Wed, Apr 23, 2008 at 07:04:35PM -0700, Toshio Kuratomi wrote: > > Matt Domsch wrote: > > >so I'm a little late requesting permission, though I was on IRC during > > >the whole "ordeal" :-) so plenty of people had a chance to object. I > > >brought up app6 as a xen guest on telia1.fp.o in Germany. It's only > > >running MM's mirrorlist server right now, but all seems fine and > > >dandy. > > > > > That's excellent. I wonder what the latency for requests is from > > app6.... (Could make some of the things that J5 is trying to do with > > myfedora even harder.) > > > > Of course, we don't have to run apps that myfedora consumes on app6 but > > it would be nice to not have to worry about physical geography when an > > emergency causes us to need to bring up other applications on a > > different app server. > > For those of us in the US, yes, it's higher. From Europe I suspect > it's faster for them than it is for us. > > Typical responses when hitting app3 and app5 are in the 0.300-0.400s range. > When hitting app6 I'm seeing around 0.800s. > > It's a shame mod_proxy_balancer doesn't grok geoip. It'd be fun for > it to default North American users to our US app servers, .EU to > Telia, with the fallback to use any of the others that are alive... > > Anyone up for some coding? :-) > WE do need some metrics there though. Those numbers could be very interesting. And I know there's tweaks to openvpn we can do. -Mike From a.badger at gmail.com Thu Apr 24 02:15:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Apr 2008 19:15:59 -0700 Subject: app6 up In-Reply-To: <20080424011455.GG12908@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> Message-ID: <480FED5F.3030808@gmail.com> Answering myself, ping times from app4 (phx-Arizona), app5.vpn (tummy-Colorado), and app6.vpn(telia-Germany) to db2(phx-Arizona) [toshio at app4 ~]$ ping db2 PING db2.fedora.phx.redhat.com (10.8.34.120) 56(84) bytes of data. 64 bytes from 10.8.34.120: icmp_seq=1 ttl=64 time=0.249 ms 64 bytes from 10.8.34.120: icmp_seq=2 ttl=64 time=0.285 ms 64 bytes from 10.8.34.120: icmp_seq=3 ttl=64 time=0.764 ms 64 bytes from 10.8.34.120: icmp_seq=4 ttl=64 time=0.280 ms [toshio at app5 ~]$ ping db2 PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=43.7 ms 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=42.9 ms 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=42.9 ms 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=42.9 ms [toshio at app6 ~]$ ping db2 PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=196 ms 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=181 ms 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=184 ms 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=186 ms So each request from an app server in phx to the database or to another app will be 200x faster to set up than from an app server at tummy and nearly 1000x faster to set up than telia. If we deploy apps at telia it will be essential to minimize the number of requests if we want to keep things fast. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Matt_Domsch at dell.com Thu Apr 24 02:25:09 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 23 Apr 2008 21:25:09 -0500 Subject: app6 up In-Reply-To: <480FED5F.3030808@gmail.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FED5F.3030808@gmail.com> Message-ID: <20080424022509.GC5316@auslistsprd01.us.dell.com> On Wed, Apr 23, 2008 at 07:15:59PM -0700, Toshio Kuratomi wrote: > So each request from an app server in phx to the database or to another > app will be 200x faster to set up than from an app server at tummy and > nearly 1000x faster to set up than telia. If we deploy apps at telia it > will be essential to minimize the number of requests if we want to keep > things fast. mirrorlist server I put there doesn't hit the database ever. It's got a private cache file updated hourly from a process run on app4. :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Thu Apr 24 02:25:32 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 21:25:32 -0500 (CDT) Subject: app6 up In-Reply-To: <480FED5F.3030808@gmail.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FED5F.3030808@gmail.com> Message-ID: latency and throughput measure different things though, we'll have to test multiple things. -Mike On Wed, 23 Apr 2008, Toshio Kuratomi wrote: > Answering myself, ping times from app4 (phx-Arizona), app5.vpn > (tummy-Colorado), and app6.vpn(telia-Germany) to db2(phx-Arizona) > > [toshio at app4 ~]$ ping db2 > PING db2.fedora.phx.redhat.com (10.8.34.120) 56(84) bytes of data. > 64 bytes from 10.8.34.120: icmp_seq=1 ttl=64 time=0.249 ms > 64 bytes from 10.8.34.120: icmp_seq=2 ttl=64 time=0.285 ms > 64 bytes from 10.8.34.120: icmp_seq=3 ttl=64 time=0.764 ms > 64 bytes from 10.8.34.120: icmp_seq=4 ttl=64 time=0.280 ms > > [toshio at app5 ~]$ ping db2 > PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. > 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=43.7 ms > 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=42.9 ms > 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=42.9 ms > 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=42.9 ms > > [toshio at app6 ~]$ ping db2 > PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. > 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=196 ms > 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=181 ms > 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=184 ms > 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=186 ms > > So each request from an app server in phx to the database or to another app > will be 200x faster to set up than from an app server at tummy and nearly > 1000x faster to set up than telia. If we deploy apps at telia it will be > essential to minimize the number of requests if we want to keep things fast. > > -Toshio > > From Matt_Domsch at dell.com Thu Apr 24 02:40:10 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 23 Apr 2008 21:40:10 -0500 Subject: app6 up In-Reply-To: <20080424021219.GB5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> Message-ID: <20080424024010.GD5316@auslistsprd01.us.dell.com> On Wed, Apr 23, 2008 at 09:12:19PM -0500, Matt Domsch wrote: > It's a shame mod_proxy_balancer doesn't grok geoip. It'd be fun for > it to default North American users to our US app servers, .EU to > Telia, with the fallback to use any of the others that are alive... http://mail-archives.apache.org/mod_mbox/httpd-users/200706.mbox/%3CBAY115-W237A9C5FD8FCA670B034B5B1130 at phx.gbl%3E gist is, we're actually proxypassing from the proxy servers to the app servers. The problem becomes, we need our US users to magically hit a US proxy server, and then be proxypassed to a US app server; likewise we need EU users to magially hit a .EU proxy server and be proxypassed to a EU app server. So it's not a mod_proxy_balancer problem as much as it is a DNS challenge - we want different answers from DNS depending on the user's location. And that's always fun... Instead, we could make proxy*.fp.o do a geoip lookup and then issue a HTTP redirect to proxy*.us.fp.o for US users, proxy*.eu.fp.o for EU users etc. And _then_ let the balancer kick in. Still, you'll have potentially high latency on that first lookup before the redirect. For mirrorlist, it's not worth it; the app answers quickly enough to any request that the whole process is overshadowed by the TCP connection setup time and transfer latency, not app processing. For apps with more "think time" though, it's something to consider. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From ivazqueznet at gmail.com Thu Apr 24 03:07:21 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 23 Apr 2008 23:07:21 -0400 Subject: app6 up In-Reply-To: <20080424024010.GD5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> <20080424024010.GD5316@auslistsprd01.us.dell.com> Message-ID: <1209006441.13044.10.camel@ignacio.lan> On Wed, 2008-04-23 at 21:40 -0500, Matt Domsch wrote: > gist is, we're actually proxypassing from the proxy servers to the app > servers. The problem becomes, we need our US users to magically hit a > US proxy server, and then be proxypassed to a US app server; likewise we > need EU users to magially hit a .EU proxy server and be proxypassed > to a EU app server. > > So it's not a mod_proxy_balancer problem as much as it is a DNS > challenge - we want different answers from DNS depending on the user's > location. And that's always fun... CentOS already does this for their mirror system. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Thu Apr 24 03:11:39 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 23 Apr 2008 22:11:39 -0500 Subject: app6 up In-Reply-To: <1209006441.13044.10.camel@ignacio.lan> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> <20080424024010.GD5316@auslistsprd01.us.dell.com> <1209006441.13044.10.camel@ignacio.lan> Message-ID: <20080424031139.GE5316@auslistsprd01.us.dell.com> On Wed, Apr 23, 2008 at 11:07:21PM -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2008-04-23 at 21:40 -0500, Matt Domsch wrote: > > gist is, we're actually proxypassing from the proxy servers to the app > > servers. The problem becomes, we need our US users to magically hit a > > US proxy server, and then be proxypassed to a US app server; likewise we > > need EU users to magially hit a .EU proxy server and be proxypassed > > to a EU app server. > > > > So it's not a mod_proxy_balancer problem as much as it is a DNS > > challenge - we want different answers from DNS depending on the user's > > location. And that's always fun... > > CentOS already does this for their mirror system. Sure, we do too with mirrormanager. For long-lived requests, it makes all sorts of sense. For very short-lived requests, where the connection setup/teardown time dominates, less interesting. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mmcgrath at redhat.com Thu Apr 24 03:13:51 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 22:13:51 -0500 (CDT) Subject: app6 up In-Reply-To: <20080424031139.GE5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> <20080424024010.GD5316@auslistsprd01.us.dell.com> <1209006441.13044.10.camel@ignacio.lan> <20080424031139.GE5316@auslistsprd01.us.dell.com> Message-ID: On Wed, 23 Apr 2008, Matt Domsch wrote: > On Wed, Apr 23, 2008 at 11:07:21PM -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2008-04-23 at 21:40 -0500, Matt Domsch wrote: > > > gist is, we're actually proxypassing from the proxy servers to the app > > > servers. The problem becomes, we need our US users to magically hit a > > > US proxy server, and then be proxypassed to a US app server; likewise we > > > need EU users to magially hit a .EU proxy server and be proxypassed > > > to a EU app server. > > > > > > So it's not a mod_proxy_balancer problem as much as it is a DNS > > > challenge - we want different answers from DNS depending on the user's > > > location. And that's always fun... > > > > CentOS already does this for their mirror system. > > Sure, we do too with mirrormanager. For long-lived requests, it makes > all sorts of sense. For very short-lived requests, where the > connection setup/teardown time dominates, less interesting. > Perception is king here, we'll want to keep an eye on these things.. As we learned with the mirror reporting script (which, IIRC, still isn't fixed but I'm positive there is one) -Mike From mmcgrath at redhat.com Thu Apr 24 03:25:17 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 23 Apr 2008 22:25:17 -0500 (CDT) Subject: app6 up In-Reply-To: <20080424031139.GE5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FEAB3.4060900@gmail.com> <20080424021219.GB5316@auslistsprd01.us.dell.com> <20080424024010.GD5316@auslistsprd01.us.dell.com> <1209006441.13044.10.camel@ignacio.lan> <20080424031139.GE5316@auslistsprd01.us.dell.com> Message-ID: On Wed, 23 Apr 2008, Matt Domsch wrote: > On Wed, Apr 23, 2008 at 11:07:21PM -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2008-04-23 at 21:40 -0500, Matt Domsch wrote: > > > gist is, we're actually proxypassing from the proxy servers to the app > > > servers. The problem becomes, we need our US users to magically hit a > > > US proxy server, and then be proxypassed to a US app server; likewise we > > > need EU users to magially hit a .EU proxy server and be proxypassed > > > to a EU app server. > > > > > > So it's not a mod_proxy_balancer problem as much as it is a DNS > > > challenge - we want different answers from DNS depending on the user's > > > location. And that's always fun... > > > > CentOS already does this for their mirror system. > > Sure, we do too with mirrormanager. For long-lived requests, it makes > all sorts of sense. For very short-lived requests, where the > connection setup/teardown time dominates, less interesting. > Its worth noting that perhaps its time to look at alternative proxy frontend. Last time I looked there were either good balancers, or good cachers, but not the both. But its quite possible we've outgrown our simple apache setup. -Mike From a.badger at gmail.com Thu Apr 24 04:25:39 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Apr 2008 21:25:39 -0700 Subject: app6 up In-Reply-To: <20080424022509.GC5316@auslistsprd01.us.dell.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FED5F.3030808@gmail.com> <20080424022509.GC5316@auslistsprd01.us.dell.com> Message-ID: <48100BC3.8060601@gmail.com> Matt Domsch wrote: > On Wed, Apr 23, 2008 at 07:15:59PM -0700, Toshio Kuratomi wrote: >> So each request from an app server in phx to the database or to another >> app will be 200x faster to set up than from an app server at tummy and >> nearly 1000x faster to set up than telia. If we deploy apps at telia it >> will be essential to minimize the number of requests if we want to keep >> things fast. > > mirrorlist server I put there doesn't hit the database ever. It's got > a private cache file updated hourly from a process run on app4. :-) > Yeah, which makes mirrorlist ideal for telia :-) myfedora, on the other hand, would be terrible to put at telia since it does a lot of requests to other fedora services which then have to do requests to the db server. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ricky at fedoraproject.org Thu Apr 24 04:32:10 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 24 Apr 2008 00:32:10 -0400 Subject: Change Request: Even newer python-fedora In-Reply-To: <480FDC34.6060101@gmail.com> References: <480FDC34.6060101@gmail.com> Message-ID: <20080424043210.GB6998@Max> On 2008-04-23 06:02:44 PM, Toshio Kuratomi wrote: > I need to get a new python-fedora on the app servers to address these > issues. Patch with the proposed code changes is attached. +1 Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Thu Apr 24 04:40:02 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Apr 2008 21:40:02 -0700 Subject: app6 up In-Reply-To: References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FED5F.3030808@gmail.com> Message-ID: <48100F22.9030309@gmail.com> Mike McGrath wrote: > latency and throughput measure different things though, we'll have to test > multiple things. > Very true. From the data we've gathered at tummy, though, I'm not nearly as concerned about throughput as latency. Latency makes every connection to the database or to a proxy server that's not in the local colo much more expensive no matter how large or small the data returned. With tummy, in fact, I know that making fewer requests trumps the amount of data returned by a large margin. The bugzilla script I optimized today to work from tummy changed how I cached data from FAS. Before I was storing people information in a cache whenever a new person was found (This hits almost everyone in cvsextras once and only a handful who are not in cvsextras). The new cache requests all of the people in FAS in two requests (getting different information about all the users from each request). The old script took hours to complete. The new one finished in under 8 minutes. (Even when the script accessed the fas1 database directly it took hours to complete... although that ran from the Red Hat Boston office, rather than tummy). -Toshio > -Mike > > On Wed, 23 Apr 2008, Toshio Kuratomi wrote: > >> Answering myself, ping times from app4 (phx-Arizona), app5.vpn >> (tummy-Colorado), and app6.vpn(telia-Germany) to db2(phx-Arizona) >> >> [toshio at app4 ~]$ ping db2 >> PING db2.fedora.phx.redhat.com (10.8.34.120) 56(84) bytes of data. >> 64 bytes from 10.8.34.120: icmp_seq=1 ttl=64 time=0.249 ms >> 64 bytes from 10.8.34.120: icmp_seq=2 ttl=64 time=0.285 ms >> 64 bytes from 10.8.34.120: icmp_seq=3 ttl=64 time=0.764 ms >> 64 bytes from 10.8.34.120: icmp_seq=4 ttl=64 time=0.280 ms >> >> [toshio at app5 ~]$ ping db2 >> PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. >> 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=43.7 ms >> 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=42.9 ms >> 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=42.9 ms >> 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=42.9 ms >> >> [toshio at app6 ~]$ ping db2 >> PING db2.vpn.fedoraproject.org (192.168.1.19) 56(84) bytes of data. >> 64 bytes from 192.168.1.19: icmp_seq=1 ttl=64 time=196 ms >> 64 bytes from 192.168.1.19: icmp_seq=2 ttl=64 time=181 ms >> 64 bytes from 192.168.1.19: icmp_seq=3 ttl=64 time=184 ms >> 64 bytes from 192.168.1.19: icmp_seq=4 ttl=64 time=186 ms >> >> So each request from an app server in phx to the database or to another app >> will be 200x faster to set up than from an app server at tummy and nearly >> 1000x faster to set up than telia. If we deploy apps at telia it will be >> essential to minimize the number of requests if we want to keep things fast. >> >> -Toshio >> >> > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Thu Apr 24 13:39:40 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 08:39:40 -0500 (CDT) Subject: Meeting today (reminder) Message-ID: There's a meeting today and we'll be discussing the release. I've been creating all of the tickets in our SOP. http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From mmcgrath at redhat.com Thu Apr 24 14:15:37 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 09:15:37 -0500 (CDT) Subject: mirrorlist data to app2 Message-ID: app2 has everything needed to run the mirrors list but the data and the balancer pointing to it. Anyone against this? -Mike From jeff at ocjtech.us Thu Apr 24 18:39:46 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 24 Apr 2008 13:39:46 -0500 Subject: configs/build/mock epel-4-i386-extras.cfg, 1.1, 1.2 epel-4-ppc-extras.cfg, 1.1, 1.2 epel-4-x86_64-extras.cfg, 1.1, 1.2 epel-5-i386-extras.cfg, 1.1, 1.2 epel-5-ppc-extras.cfg, 1.1, 1.2 epel-5-x86_64-extras.cfg, 1.1, 1.2 In-Reply-To: <20080424182852.C37B11036A@puppet1.fedora.phx.redhat.com> References: <20080424182852.C37B11036A@puppet1.fedora.phx.redhat.com> Message-ID: <935ead450804241139o388cc494xd472ea5d29b31eb@mail.gmail.com> On Thu, Apr 24, 2008 at 1:28 PM, Dennis Gilmore wrote: > > --- epel-4-i386-extras.cfg 18 Apr 2007 19:55:07 -0000 1.1 > +++ epel-4-i386-extras.cfg 24 Apr 2008 18:28:52 -0000 1.2 > @@ -43,10 +43,9 @@ > name=core > baseurl=file:///mnt/ntap-fedora1/scratch/RHEL4/en/os/RPMS/i386/ > > -# We dont have an updates tree but probably should add it > -#[updates-released] > -#name=updates > -#baseurl=file:///pub/fedora/linux/core/updates/5/i386/ > +[updates-released] > +name=updates > +baseurl=file:///pub/fedora/linux/core/updates/5/i386/ Shouldn't these be pointing to the version 4 updates? Jeff From dennis at ausil.us Thu Apr 24 18:45:58 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 24 Apr 2008 13:45:58 -0500 Subject: configs/build/mock epel-4-i386-extras.cfg, 1.1, 1.2 epel-4-ppc-extras.cfg, 1.1, 1.2 epel-4-x86_64-extras.cfg, 1.1, 1.2 epel-5-i386-extras.cfg, 1.1, 1.2 epel-5-ppc-extras.cfg, 1.1, 1.2 epel-5-x86_64-extras.cfg, 1.1, 1.2 In-Reply-To: <935ead450804241139o388cc494xd472ea5d29b31eb@mail.gmail.com> References: <20080424182852.C37B11036A@puppet1.fedora.phx.redhat.com> <935ead450804241139o388cc494xd472ea5d29b31eb@mail.gmail.com> Message-ID: <200804241346.09497.dennis@ausil.us> On Thursday 24 April 2008, Jeffrey Ollie wrote: > On Thu, Apr 24, 2008 at 1:28 PM, Dennis Gilmore wrote: > > --- epel-4-i386-extras.cfg 18 Apr 2007 19:55:07 -0000 1.1 > > +++ epel-4-i386-extras.cfg 24 Apr 2008 18:28:52 -0000 1.2 > > @@ -43,10 +43,9 @@ > > name=core > > baseurl=file:///mnt/ntap-fedora1/scratch/RHEL4/en/os/RPMS/i386/ > > > > -# We dont have an updates tree but probably should add it > > -#[updates-released] > > -#name=updates > > -#baseurl=file:///pub/fedora/linux/core/updates/5/i386/ > > +[updates-released] > > +name=updates > > +baseurl=file:///pub/fedora/linux/core/updates/5/i386/ > > Shouldn't these be pointing to the version 4 updates? They were completely wrong i'm fixing now Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Thu Apr 24 19:17:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 14:17:58 -0500 (CDT) Subject: app6 up In-Reply-To: <48100F22.9030309@gmail.com> References: <20080424011455.GG12908@auslistsprd01.us.dell.com> <480FED5F.3030808@gmail.com> <48100F22.9030309@gmail.com> Message-ID: On Wed, 23 Apr 2008, Toshio Kuratomi wrote: > Mike McGrath wrote: > > latency and throughput measure different things though, we'll have to test > > multiple things. > > > Very true. From the data we've gathered at tummy, though, I'm not nearly as > concerned about throughput as latency. Latency makes every connection to the > database or to a proxy server that's not in the local colo much more expensive > no matter how large or small the data returned. With tummy, in fact, I know > that making fewer requests trumps the amount of data returned by a large > margin. > so here's a simple and non-dedicated test against our current environment. In the first tab I hit app2,3,4,5,6. App5 and 6 are not in PHX. One thing you'll notice is that our remote hosts have a much higher max request time though 90% of the requests were handled in the same ballpark as the local machines. Also, for some reason, app5 is responding more quickly then app4. initially I'm suspecting this is because app2,3,5 are i386 and app4,6 are x86_64. I'm going to run some more tests and verify that. Also in the longer tests, where I hit app servers directly with concurrent requests over time, aside from the drop outs (still looking in to wtf happened there) I'd say we're in pretty good shape. Way way beyond capacity for normal days. I'll look at what the last release looked like but mirrormanager also was no problem for the last release. -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: Benchmarks.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 62892 bytes Desc: URL: From ricky at fedoraproject.org Thu Apr 24 20:41:16 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 24 Apr 2008 16:41:16 -0400 Subject: Meeting Log - 2008-04-24 Message-ID: <20080424204116.GA1398@Max> 15:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here? 15:59 < mmcgrath> Lets get started, who's around? 16:00 < G> moo 16:00 * ricky 16:00 -!- techbugs [n=siddhart at 60.254.79.190] has joined #fedora-meeting 16:00 -!- jgraham [n=jgraham at c-24-91-211-27.hsd1.ma.comcast.net] has joined #fedora-meeting 16:00 < ivazquez> Pong. 16:00 * dgilmore is present and accounted for 16:00 * abadger1999 here 16:00 < jcollie> yo 16:00 * yingbull is here. 16:01 < mmcgrath> Lets get right to it 16:01 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The release 16:01 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/milestone/Fedora%209 16:01 < zodbot> mmcgrath: http://tinyurl.com/4h93pm 16:02 < mmcgrath> We've still got some things to do for this release (many are related to the release directly. 16:02 < mmcgrath> .ticket 421 16:02 < zodbot> mmcgrath: #421 (Fedora Mirror Space) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/421 16:02 < mmcgrath> f13: ping 16:02 < dgilmore> mmcgrath: he is not around 16:02 < mmcgrath> oh right, I forgot about that 16:03 < mmcgrath> .any mdomsch 16:03 < zodbot> mmcgrath: mdomsch was last seen in #fedora-meeting 16 hours, 24 minutes, and 3 seconds ago: *** mdomsch has quit IRC ("Leaving") 16:03 < mmcgrath> also not around 16:03 < ricky> Yeah, I think he said he wouldn't be around today 16:03 < mmcgrath> .ticket 438 16:03 < zodbot> mmcgrath: #438 (Fix CLA process on wiki for ease of use) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/438 16:04 < mmcgrath> ricky: thats assigned to you me and paulobanon. Whats the status of it :) ? 16:04 -!- XulChris [i=xulchris at adsl-75-0-4-184.dsl.renocs.sbcglobal.net] has quit Read error: 110 (Connection timed out) 16:04 -!- XulChris_ is now known as XulChris 16:04 -!- cebbert [n=cebbert at 14.sub-75-223-51.myvzw.com] has left #fedora-meeting ["Leaving"] 16:04 < ricky> Waiting on mediawiki, I guess. At that point, we can probably link to a FAS signup link from the login page 16:04 < mmcgrath> k, if thats blocking on mediawiki go ahead and move it to an F10 milestone. 16:05 < mmcgrath> .ticket 17 16:05 < zodbot> mmcgrath: #17 (Secondary Arch Support) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/17 16:05 < mmcgrath> dgilmore: ? 16:05 -!- mether [n=ask at fedora/mether] has quit Read error: 113 (No route to host) 16:06 < mmcgrath> dgilmore: ping 16:06 < dgilmore> mmcgrath: changed to F10 16:06 < mmcgrath> solid 16:06 < dgilmore> mmcgrath: its still not fully done 16:06 < mmcgrath> .ticket 54 16:06 < zodbot> mmcgrath: #54 (Postfix Server) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/54 16:06 < mmcgrath> so this one's still on the list 16:06 < dgilmore> gahh we suck 16:07 < mmcgrath> dgilmore: I'm thinking about doing that after the meeting / tomorrow. Mind if I snag that one? 16:07 < dgilmore> well i suck 16:07 -!- fabian_a [n=fabian at 84-75-175-46.dclient.hispeed.ch] has joined #fedora-meeting 16:07 < dgilmore> mmcgrath: have at it 16:07 < mmcgrath> k 16:07 < mmcgrath> .ticket 272 16:07 < zodbot> mmcgrath: #272 (Reversing the netapp sync) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/272 16:07 < mmcgrath> Thats done, we can close that 16:07 < mmcgrath> .ticket 280 16:07 < zodbot> mmcgrath: #280 (DHCP Server off of lockbox) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/280 16:07 < mmcgrath> Thats mostly done. I just need to copy the file and start up the service. 16:07 < mmcgrath> .ticket 333 16:07 < zodbot> mmcgrath: #333 (Add spam headers to bastion (smtp)) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/333 16:07 < mmcgrath> Thats blocking on 54 (mentioned above) I'll get to working on that tonight / tomorrow as well. 16:07 < mmcgrath> .ticket 411 16:07 < mmcgrath> ricky: ping 16:07 < zodbot> mmcgrath: #411 (New Website Fedora - 9) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/411 16:08 < mmcgrath> speak brother! 16:08 < ricky> OK, so no huge changes for this release, just need to email l10n to get translations ready 16:08 < mmcgrath> do we have an agreement with them or anything on how quick in advance the website needs to be done? 16:09 < ricky> Pretty much up to the last moment, when we do the final push (although earlier is always better :)) 16:10 < mmcgrath> 16:10 < mmcgrath> .ticket 416 16:10 < zodbot> mmcgrath: #416 (Infrastructure Change Freeze) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/416 16:10 < ricky> Previously, we were planning to freeze for translation 7 days in advance, so we're in good shape with the delayed release. 16:10 < mmcgrath> ricky: ahh, excellent. 16:10 -!- kennyt [n=ken at species.umd.edu] has joined #fedora-meeting 16:10 < mmcgrath> So the change freeze got pushed back (sort of) 16:10 < mmcgrath> we're in a "announce everything approve almost everything" phase. But that will change next week when we lock it down tighter. 16:11 < mmcgrath> .ticket 506 16:11 < zodbot> mmcgrath: #506 (Advertisement for FOSS used in infrastructure) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/506 16:11 < mmcgrath> wtf is that? 16:11 * mmcgrath clicky 16:11 < mmcgrath> ricky: thats currently assigned to you, mind moving it to F10? 16:11 < ricky> Sure thing 16:12 < mmcgrath> .ticket 34 16:12 < zodbot> mmcgrath: #34 (Voting app should include confirmation page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/34 16:12 < mmcgrath> abadger1999: ping 16:12 < mmcgrath> G: ping 16:12 < abadger1999> I'll push this one back to F10 16:12 < G> That can be posted on the elections trac :) 16:12 < mmcgrath> so you two have been working on re-building the app completely right? 16:12 < abadger1999> But the good news is G is working on that! 16:12 < mmcgrath> excellent. 16:12 < mmcgrath> k, move that to a F10 target then. 16:12 < mmcgrath> .ticket 226 16:12 < zodbot> mmcgrath: #226 (update log analyzer configuration on lockbox) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/226 16:12 < mmcgrath> yingbull: ping 16:13 < yingbull> pong 16:13 < yingbull> I'm working on this one. 16:13 < mmcgrath> yingbull: mind talking a bit about the log analyzer? Its a F9 target, should we push that back to F10? 16:13 < lmacken> so yeah, these daily mails have gotten a bit out of control 16:13 < yingbull> We can do this before the freeze. 16:13 < yingbull> Ok, so the deal is... 16:14 * mmcgrath was hoping he'd say that :) 16:14 < yingbull> The daily emails got huge after a puppet error filled them afew days ago (really huge). 16:14 < yingbull> I believe that is fixed now. 16:14 < yingbull> So I'm going to see tomorrow what it looks like. 16:14 < mmcgrath> so whats the next biggest offender? 16:14 < lmacken> 8153 Apr 24 root ( 39M) Fedora Infrastructure system events: Thu Apr 24 10:28:42 2 16:14 < yingbull> Puppet, still. 16:14 < mmcgrath> :) 16:14 < yingbull> Even before the errors, there was a lot of noise. 16:15 < yingbull> I'm going to weedeater most if not all of puppet. 16:15 < yingbull> Once that's out of the way, its a lot more manageable and it'll be easier to see what needs to be done. 16:15 < lmacken> long term, I think a nice web-interface with nagios-style notifications for errors would be a nice solution to handling our logs, not just for machines but apps as well 16:15 < yingbull> I figure I'll just weedeater whatever the big offender is each day, till its manageable -- or create tickets to fix the problem, of course, if its a problem the logs are reporting. 16:16 < yingbull> Zenoss has some nice integration with syslog for events. 16:16 < lmacken> as a side project, I started writing an expert system that handles real-time analysis of logs, which I've been feeding fedora's logs into it. May be a potential solution :\ 16:16 -!- techbugs [n=siddhart at 60.254.79.190] has quit "Leaving." 16:16 < ricky> Cool 16:16 < abadger1999> Is there a possibility to leave it as plain text instead of html? 16:16 < yingbull> lmacken: Sounds good. epylog seems to be the best we've got at the moment, and I think as long as the noise is out so we get better signal:noise, it'll be adaquate. 16:17 < mmcgrath> yingbull: the future is wide open there. If you've got somethign in mind just let us know. If you think you can put something together though we're all for it. 16:17 < jcollie> lmacken: too bad splunk is not open source 16:17 < yingbull> abadger1999: Yes, it can be set to do plain text. 16:17 < lmacken> yingbull: sure. My problem is that too much stuff goes unparsed, and our TG apps aren't even being monitored 16:17 < lmacken> jcollie: my app will hopefully be a good contender to that 16:17 < yingbull> but it's all or nothing, unless we run it twice. 16:17 < mmcgrath> dgilmore: ping, do you know why puppet keeps getting auto updated on the builders? 16:17 < jcollie> lmacken: have you published the source anywhere? i need something like that at work 16:18 < mmcgrath> yingbull: would you do me a favor and just ignore all puppet traffic for now? 16:18 -!- k0k [n=k0k at fedora/k0k] has quit Remote closed the connection 16:18 < yingbull> lmacken: I'm going to try and have stuff either parsed, or weedeatered, or gone. I don't think it should be too bad. 16:18 < abadger1999> yingbull: I would appreciate that as html mail makes my stupid graphical reader crawl. 16:18 < mmcgrath> yingbull: we're in a particularly interesting period where its generating lots of crap but we'll be fixing that with the upgrade. Then we can un-ignore it. 16:18 < yingbull> mmcgrath: sure can, I'll change that today and run the logs again. 16:18 < lmacken> jcollie: not yet, but I'll try and whip the code into shape soon. My buddy at google wrote the crazy parsing code in thebackend, and recently wrote python bindings. So I'll hack on it a bit and try and release it at some point after F9 :) 16:18 < jcollie> lmacken: cool 16:19 < mmcgrath> yingbull: thanks 16:19 < yingbull> abadger1999, mmcgrath: I can set it text but it would be global. 16:19 < lmacken> yingbull: thanks for keeping this ball rolling 16:19 < yingbull> lmacken: No problem. I have access enough now I can do this :-) 16:19 < lmacken> good good 16:19 < yingbull> Do we want text versions? 16:20 < abadger1999> Well...anyone against emitting plain text for the log messages? 16:20 < yingbull> Should I run it once and we can see if its horrid? 16:20 < lmacken> sure 16:20 < lmacken> my mutt config throws html emails at w3m before viewing, so it doesn't make a difference to me :\ 16:20 < abadger1999> sounds like a good plan. 16:20 * mmcgrath prefers plain text but is open to whatever. 16:20 < yingbull> OK, I'll change it to text and we'll go from there. 16:21 < mmcgrath> yingbull: sounds good, anything else? 16:21 < dgilmore> mmcgrath: not sure 16:22 < dgilmore> mmcgrath: I did not intentinally enable autoupdates 16:22 < mmcgrath> 16:22 < mmcgrath> the last ticket for this milestone is 16:22 < mmcgrath> .ticket 231 16:22 < zodbot> mmcgrath: #231 (post master directory space usage for mirrors) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/231 16:23 < mmcgrath> This should be doable by then. I'll have to talk to jesse about where to put it. 16:23 < mmcgrath> So thats the last ticket related to the release. Anyone have anything release oriented they'd like to discuss? 16:23 -!- tibbs [n=tibbs at fedora/tibbs] has quit "Konversation terminated!" 16:24 < mmcgrath> k, then we'll move on to the normal tickets 16:24 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets! 16:24 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority 16:24 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6 16:24 < mmcgrath> .ticket 519 16:24 < zodbot> mmcgrath: #519 (Network outage PHX - 2008-05-03 14:00 UTC) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/519 16:24 < mmcgrath> oy. Thats going to be rough. 16:25 < mmcgrath> so my plan is to shut down any iscsi machines during that outage and let nfs do its thing when it loses and gets a connection back. 16:25 -!- jmtaylor [n=jason at fedora/jmtaylor] has joined #fedora-meeting 16:25 < mmcgrath> We'll be running the website out of tummy.com then so the wiki will go up and down but, in theory, mirrormanager and the mirrorlist should be fine. 16:25 < mmcgrath> Anyone have any special concerns / questions about that? 16:26 < mmcgrath> k 16:26 < mmcgrath> .ticket 395 16:26 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395 16:26 < mmcgrath> jcollie: any progress on that by chance? 16:27 < jcollie> no, been busy with lots of stuff with $DAYJOB and $FAMILYSTUFF 16:27 < mmcgrath> k 16:27 < mmcgrath> .ticket 398 16:27 < zodbot> mmcgrath: #398 (elfutils `monotone' (mtn) error) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/398 16:27 < mmcgrath> I've not heard anythign on this but I've not looked either 16:27 * mmcgrath tries to get ahold of rmcgrath 16:27 < abadger1999> It looked like upstream had a program that might help. 16:27 < abadger1999> Did anyone look into that? (usher) 16:27 * mmcgrath hasn't looked at that problem in weeks. 16:28 < abadger1999> It's mentioned in the upstream ticket and I copied it to ours but rmcgrath hasn't responded with an eval of whether it would work for us. 16:28 < mmcgrath> k 16:29 < mmcgrath> and I can't get ahold of rmcgrath in #fedora-admin so we'll have to come back another time 16:29 < mmcgrath> .ticket 446 16:29 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/446 16:29 < mmcgrath> dgilmore: ping? I think you were working on wiki links for this or something. Any progress? 16:30 < dgilmore> mmcgrath: i started on it and forgot again 16:30 < dgilmore> i need to get my ass kciked 16:30 * mmcgrath kicks dgilmore's ass :) 16:31 < mmcgrath> dgilmore: so no progress? 16:31 < dgilmore> ouch 16:31 < dgilmore> mmcgrath: not enough to report on 16:31 < mmcgrath> we'll save that for next week then. 16:31 < mmcgrath> Thats all I really had for this meeting so I'll open the floor. 16:31 < McGiwer> oh abadger1999 16:31 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor 16:31 < McGiwer> beautiful year 16:31 < mmcgrath> anyone have anything they'd like to discuss? 16:32 < dgilmore> mmcgrath: a little yeah 16:32 < mmcgrath> dgilmore: ? 16:32 < McGiwer> hmm, u're having some meeting, bye ;. 16:32 < McGiwer> ;> 16:32 < dgilmore> as everyone knows i went to Brazil last week 16:32 < mmcgrath> mhmm 16:33 < dgilmore> other than excelent food and people 16:33 -!- stickster_ [n=pfrields at ip72-209-237-99.dc.dc.cox.net] has joined #fedora-meeting 16:33 < dgilmore> I realised that its extremely necesary to have localised spins for livecds etc 16:33 < dgilmore> which then brought up hosting 16:33 -!- stickster [n=nnpaul at fedora/stickster] has quit Nick collision from services. 16:34 < dgilmore> i think that they should be hosted in the countires in question 16:34 -!- stickster_ is now known as stickster 16:34 < dgilmore> a big reason is the high cost of international links in some countires 16:34 < mmcgrath> who pays for th einternational links? 16:34 < mmcgrath> or are you talking about low throughput? 16:35 < dgilmore> so mostly i wanted to bring up the idea of finding hosting in different countries for localised content 16:35 < mmcgrath> I've pinged the ambassadors in the past a couple of times about hosting. Not much came back (some did) but not much. 16:35 < dgilmore> low thoughput,/ cost from ISP's for using them 16:35 < mmcgrath> shouldn't torrents fix that? 16:35 < G> dgilmore: in some countries, the international link is fine, but it's the cost of the final mile :) 16:35 -!- jgraham [n=jgraham at c-24-91-211-27.hsd1.ma.comcast.net] has quit "Ex-Chat" 16:36 < dgilmore> G: well yes Oz and NZ are special 16:36 < mmcgrath> I only bring it up because we have a torrent box (sort of once we can get this hardware issue figured out) that should be able to host quite a few localized spins. 16:36 < dgilmore> mmcgrath: that will partly help 16:36 < dgilmore> as long as we get enough seeders locally 16:37 < mmcgrath> well in general I'm for that but I'm not sure how we'd implement it. 16:37 < dgilmore> anyways i just wanted to bring up the topic 16:37 < mmcgrath> Finding 500M to a couple G might not be that difficult. 16:37 < mmcgrath> its a good topic 16:37 < dgilmore> get it on the radar 16:37 < mmcgrath> cool 16:38 < mmcgrath> dgilmore: please do open a ticket if you want to discuss it in the future. We can track ideas there and send the localization teams there for ideas. 16:38 < dgilmore> thats all i wanted to bring up 16:38 < mmcgrath> anyone have anything else to discuss? 16:38 < dgilmore> :) 16:38 < dgilmore> will do 16:38 < mmcgrath> if not we'll close in 30 16:39 < mmcgrath> 10 16:39 < mmcgrath> 5 16:39 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting End -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu Apr 24 20:57:29 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 15:57:29 -0500 (CDT) Subject: Change requests Message-ID: I'd like to complete the following changes. Ticket 333: spam headers on bastion Ticket 54: move to postgres on bastion Ticket 280: move dhcp from lockbox to somewhere else. -Mike From dennis at ausil.us Thu Apr 24 21:01:52 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 24 Apr 2008 16:01:52 -0500 Subject: Change requests In-Reply-To: References: Message-ID: <200804241601.58727.dennis@ausil.us> On Thursday 24 April 2008, Mike McGrath wrote: > I'd like to complete the following changes. > > Ticket 333: spam headers on bastion +1 > Ticket 54: move to postgres on bastion +1 i assume you mean postfix > Ticket 280: move dhcp from lockbox to somewhere else. +1 also. i hope lockbox can die soon Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Thu Apr 24 21:06:35 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 16:06:35 -0500 (CDT) Subject: Change requests In-Reply-To: <200804241601.58727.dennis@ausil.us> References: <200804241601.58727.dennis@ausil.us> Message-ID: On Thu, 24 Apr 2008, Dennis Gilmore wrote: > On Thursday 24 April 2008, Mike McGrath wrote: > > I'd like to complete the following changes. > > > > Ticket 333: spam headers on bastion > +1 > > > Ticket 54: move to postgres on bastion > +1 i assume you mean postfix > I think the betawaves in my brain do that because I do it a lot. > > Ticket 280: move dhcp from lockbox to somewhere else. > +1 also. i hope lockbox can die soon > It will soon. We're waiting on a purchase to go through. -Mike From mmcgrath at redhat.com Thu Apr 24 21:43:19 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 16:43:19 -0500 (CDT) Subject: Change request (< stickster> mmcgrath: Can we get "join.fedoraproject.org" -> "fedoraproject.org/join-fedora"?) Message-ID: Paul would like to have join.fp.o redirect to fedoraproject.org/join-fedora. Can I get a +1? -Mike From dev at nigelj.com Thu Apr 24 21:48:08 2008 From: dev at nigelj.com (Nigel Jones) Date: Fri, 25 Apr 2008 09:48:08 +1200 (NZST) Subject: Change request (< stickster> mmcgrath: Can we get "join.fedoraproject.org" -> "fedoraproject.org/join-fedora"?) In-Reply-To: References: Message-ID: <63254.202.154.156.240.1209073688.squirrel@webmail.nigelj.com> > > Paul would like to have join.fp.o redirect to > fedoraproject.org/join-fedora. Can I get a +1? Amen to that! +1 Can we get a Hallelujah? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From a.badger at gmail.com Thu Apr 24 21:51:21 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 24 Apr 2008 14:51:21 -0700 Subject: Change request (< stickster> mmcgrath: Can we get "join.fedoraproject.org" -> "fedoraproject.org/join-fedora"?) In-Reply-To: <63254.202.154.156.240.1209073688.squirrel@webmail.nigelj.com> References: <63254.202.154.156.240.1209073688.squirrel@webmail.nigelj.com> Message-ID: <481100D9.6010307@gmail.com> Nigel Jones wrote: >> Paul would like to have join.fp.o redirect to >> fedoraproject.org/join-fedora. Can I get a +1? > Amen to that! +1 > > Can we get a Hallelujah? Hallelujah brother! +1 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Fri Apr 25 02:09:03 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Apr 2008 22:09:03 -0400 Subject: Change requests In-Reply-To: References: <200804241601.58727.dennis@ausil.us> Message-ID: <1209089343.15548.11.camel@cutter> On Thu, 2008-04-24 at 16:06 -0500, Mike McGrath wrote: > On Thu, 24 Apr 2008, Dennis Gilmore wrote: > > > On Thursday 24 April 2008, Mike McGrath wrote: > > > I'd like to complete the following changes. > > > > > > Ticket 333: spam headers on bastion > > +1 > > > > > Ticket 54: move to postgres on bastion > > +1 i assume you mean postfix > > > > I think the betawaves in my brain do that because I do it a lot. > okay - I'll be honest here. I think we're too close to the freeze to do this. The last thing we need is mail forwarding being bollocksed up for a few hours right now. -sv From mmcgrath at redhat.com Fri Apr 25 03:15:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Apr 2008 22:15:47 -0500 (CDT) Subject: Change requests In-Reply-To: <1209089343.15548.11.camel@cutter> References: <200804241601.58727.dennis@ausil.us> <1209089343.15548.11.camel@cutter> Message-ID: On Thu, 24 Apr 2008, seth vidal wrote: > On Thu, 2008-04-24 at 16:06 -0500, Mike McGrath wrote: > > On Thu, 24 Apr 2008, Dennis Gilmore wrote: > > > > > On Thursday 24 April 2008, Mike McGrath wrote: > > > > I'd like to complete the following changes. > > > > > > > > Ticket 333: spam headers on bastion > > > +1 > > > > > > > Ticket 54: move to postgres on bastion > > > +1 i assume you mean postfix > > > > > > > I think the betawaves in my brain do that because I do it a lot. > > > > okay - I'll be honest here. I think we're too close to the freeze to do > this. The last thing we need is mail forwarding being bollocksed up for > a few hours right now. > A fair objection. I've got the configs ready, I see no real reason to deploy them now. We can wait till after F9. Its certainly not a blocker for the release and the risk is a real one. -Mike From jan_janssens at edpnet.be Fri Apr 25 06:59:55 2008 From: jan_janssens at edpnet.be (Jan Janssens) Date: Fri, 25 Apr 2008 08:59:55 +0200 Subject: short Introduction Message-ID: <1209106795.5197.9.camel@localhost.localdomain> Hi all, My name is Jan Janssens. I live in Belgium and I'm new to the fedora project. I have some professional experience with pound, apache, bind, open-ldap and I want to help with the infrastructure side of the fedora project. I'm on IRC with the nickname jjs. Please feel free to contact me if you want to know more about me. Regards, Jan From sebastian.gosenheimer at proio.com Fri Apr 25 09:40:19 2008 From: sebastian.gosenheimer at proio.com (Sebastian Gosenheimer - proIO Network & eSolutions e.K.) Date: Fri, 25 Apr 2008 11:40:19 +0200 Subject: Introduction - Sebastian Gosenheimer Message-ID: <20080425094019.c2c15e1c@mail.proio.com> Hi, my name is Sebastian Gosenheimer and i live in Frankfurt am Main, Germany. I'm working for a company which is mainly active in remote hands for datacenters located in Frankfurt. I am also responsible for some managed Linux machines. My duties are primarily that of a system administrator for Red Hat and Debian-based machines. In my freetime i'm a student of Information Technolgy. In #fedora-admin you will find me under sebastian^. Don?t hesitate to contact me if you want to know more about me. With kind regards, --sg Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From mmcgrath at redhat.com Fri Apr 25 13:11:57 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Apr 2008 08:11:57 -0500 (CDT) Subject: short Introduction In-Reply-To: <1209106795.5197.9.camel@localhost.localdomain> References: <1209106795.5197.9.camel@localhost.localdomain> Message-ID: On Fri, 25 Apr 2008, Jan Janssens wrote: > Hi all, > > My name is Jan Janssens. I live in Belgium and I'm new to the fedora > project. I have some professional experience with pound, apache, bind, > open-ldap and I want to help with the infrastructure side of the fedora > project. I'm on IRC with the nickname jjs. > Please feel free to contact me if you want to know more about me. > Welcome Jan, I'll want to talk to you a little bit about pound, probably on IRC :) -Mike From mmcgrath at redhat.com Fri Apr 25 13:15:23 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Apr 2008 08:15:23 -0500 (CDT) Subject: Introduction - Sebastian Gosenheimer In-Reply-To: <20080425094019.c2c15e1c@mail.proio.com> References: <20080425094019.c2c15e1c@mail.proio.com> Message-ID: On Fri, 25 Apr 2008, Sebastian Gosenheimer - proIO Network & eSolutions e.K. wrote: > Hi, > > my name is Sebastian Gosenheimer and i live in Frankfurt am Main, Germany. > I'm working for a company which is mainly active in remote hands for datacenters > located in Frankfurt. > I am also responsible for some managed Linux machines. My duties are primarily > that of a system administrator for Red Hat and Debian-based machines. > > In my freetime i'm a student of Information Technolgy. In #fedora-admin you will > find me under sebastian^. > > Don?t hesitate to contact me if you want to know more about me. > Welcome Sebastian! For those that don't, proIO is one of our sponsors: http://fedoraproject.org/sponsors Providing remote hands for our german colo. Good to have you around Sebastian. Please attend some of our meetings when you're available: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike From schaiba at gmail.com Fri Apr 25 18:39:17 2008 From: schaiba at gmail.com (Aioanei Rares) Date: Fri, 25 Apr 2008 21:39:17 +0300 Subject: Introduction - Aioanei Rares Message-ID: <778179b00804251139u5c38175fo145f4911970722bd@mail.gmail.com> Hi, my name is Aioanei Rares from Romania, I'm 29, i work as a shop manager at one of the biggest computer hardware retailers around here (http://www.depozituldecalculatoare.ro/) and I like programming in my (scarcely available) spare time. My knowledge consists of some C, C# (mono), Python, databases (mainly Postgres) and of course I want to know more all the time. I would like to help the Fedora Project in any way I can, also maybe with translations - I'm an English major - so...drop me a line for more info. Have a great weekend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca at foppiano.org Sat Apr 26 07:21:45 2008 From: luca at foppiano.org (Luca Foppiano) Date: Sat, 26 Apr 2008 09:21:45 +0200 Subject: introduce myself Message-ID: <1209194505.3764.47.camel@sboing.byte-code.lan> Hi all, I'm Luca Foppiano, I come from Italy (near Milan). I've been in this ML for two months but I don't know yet which area I prefer into fedora-infrastructure. I know python and web programming (but I prefer python :P), I had some experiences on apache, lighttpd, Fedora Directory server and xen infrastructure. I'm here because I want help fedora project, but also to improve my skill and experiences. My nick on irc is lfoppiano (or, sometimes whitenoise). Best regards Luca -- Today is Sweetmorn, the 43rd day of Discord in the YOLD 3174 From dev at nigelj.com Sat Apr 26 13:31:10 2008 From: dev at nigelj.com (Nigel Jones) Date: Sun, 27 Apr 2008 01:31:10 +1200 (NZST) Subject: ** ACKNOWLEDGEMENT alert - xenbuilder1.fedora.phx.redhat.com/Swap is CRITICAL ** Message-ID: <63118.202.154.156.240.1209216670.squirrel@webmail.nigelj.com> I acknowledged this in Nagios with the hope I'd be able to find someone to kill the eclipse build and hopefully fix this all up before I went to sleep, alas no one has been around. What has happened is java has thrown and exception, but hasn't exited properly so it needs killing... So if someone can kill build ID 583255 (and resubmit) I'd imagine it'd solve the problem. Dunka Nigel's Bed :) > ***** Nagios ***** > > Notification Type: ACKNOWLEDGEMENT > > Service: Swap > Host: xenbuilder1.fedora.phx.redhat.com > Address: xenbuilder1.fedora.phx.redhat.com > State: CRITICAL > > Date/Time: Sat Apr 26 11:55:19 UTC 2008 > > Additional Info: > > SWAP CRITICAL - 10% free (293 MB out of 3071 MB) > From mmcgrath at redhat.com Sat Apr 26 15:24:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 26 Apr 2008 10:24:46 -0500 (CDT) Subject: ** ACKNOWLEDGEMENT alert - xenbuilder1.fedora.phx.redhat.com/Swap is CRITICAL ** In-Reply-To: <63118.202.154.156.240.1209216670.squirrel@webmail.nigelj.com> References: <63118.202.154.156.240.1209216670.squirrel@webmail.nigelj.com> Message-ID: On Sun, 27 Apr 2008, Nigel Jones wrote: > I acknowledged this in Nagios with the hope I'd be able to find someone to > kill the eclipse build and hopefully fix this all up before I went to > sleep, alas no one has been around. > > What has happened is java has thrown and exception, but hasn't exited > properly so it needs killing... > > So if someone can kill build ID 583255 (and resubmit) I'd imagine it'd > solve the problem. > > Dunka > Killed, thanks for the catch. -Mike From a.badger at gmail.com Sat Apr 26 17:38:51 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 26 Apr 2008 10:38:51 -0700 Subject: Fedora Services API Message-ID: <481368AB.40803@gmail.com> Hey guys, I'm talking especially to the web app developers here, but I also hope that other people will chime in with useful thoughts. As part of python-fedora, I've started documenting some standards for Fedora Services. These will go hand in hand with documents on how to use BaseClient that I am in the process of writing. These documents will document how Fedora Services should be written rather than how they are currently implemented. As such, I want to make sure everyone: 1) has a chance to review the document and make comments/changes before the changesare integrated into BaseClient and people have to port to things that are backwards incompatible. 2) can bring up other areas that need to be addressed. For instance, skvidal recently wrote a short client to the pkgdb that can generate email aliases for packages (so package at packages.fp.o could send mail to all the committers to a package). He had the following comments to make: 1) It would be nice to have an introspection API to look at what methods are available on a TG app and how to use them. 2) JSON data that is deeply nested sucks because objects are turned into dictionaries so you have to write things like: package['listings']['F-8']['people']['toshio']['acls']['commit']['status'] to get the status of a person's acls on a package. I'd like to get other people's input on how to work on these and any other issues before completing the next python-fedora so I can be sure that I've got most of the incompatibilities in. Talking here and on IRC is welcome. Here's the current version of the Fedora Services Documentation. What's there should be complete. Addressing skvidal's concerns hasn't even been stubbed out yet:: http://tinyurl.com/52xmjw The BaseClient Documentation is still in heavy flux. It's here:: http://tinyurl.com/4ww6v7 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Sat Apr 26 21:25:59 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 26 Apr 2008 16:25:59 -0500 (CDT) Subject: introduce myself In-Reply-To: <1209194505.3764.47.camel@sboing.byte-code.lan> References: <1209194505.3764.47.camel@sboing.byte-code.lan> Message-ID: On Sat, 26 Apr 2008, Luca Foppiano wrote: > Hi all, > I'm Luca Foppiano, I come from Italy (near Milan). > I've been in this ML for two months but I don't know yet which area I > prefer into fedora-infrastructure. > > I know python and web programming (but I prefer python :P), I had some > experiences on apache, lighttpd, Fedora Directory server and xen > infrastructure. > > I'm here because I want help fedora project, but also to improve my > skill and experiences. > Welcome Luca, have you any experience with python and turbogears? -Mikex From jesusr at redhat.com Sun Apr 27 04:59:29 2008 From: jesusr at redhat.com (Jesus M. Rodriguez) Date: Sun, 27 Apr 2008 00:59:29 -0400 Subject: Fedora Services API In-Reply-To: <481368AB.40803@gmail.com> References: <481368AB.40803@gmail.com> Message-ID: <20080427045929.GK12555@transam.devel.redhat.com> On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: [snip] > 2) JSON data that is deeply nested sucks because objects are turned into > dictionaries so you have to write things like: > > package['listings']['F-8']['people']['toshio']['acls']['commit']['status'] > > to get the status of a person's acls on a package. When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) where create_tree is an object creation method. The other option is to change the depth of the object returned. -- jesus m. rodriguez | jesusr at redhat.com sr. software engineer | irc: zeus red hat network | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +-------------------------------------------+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +-------------------------------------------+ From thinklinux.ssh at gmail.com Sun Apr 27 05:41:54 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sun, 27 Apr 2008 11:11:54 +0530 Subject: How much downtime do we afford for nagios? Message-ID: Hi, For a few days false notification of nagios reduced. But it has increased again. Looking at the /configs/system/nagios/services/template.cfg reveals that it is configured as max_check_attempt = 4 and retry_check_interval 1 for hosts and max_check_attempts = 3 and retry_check_interval 1. So if a service or host is unreachable for 3 or 4 mins, we get a notification. (However most of the cases it is false positive, due to congestion or others). How about finding out a working delay which we can afford, if a service or host is really down. How about 10 mins ? (5 attempt x 2 mins?). Also we may list services/host which are critical and which are not. That will help to define different notification period for the different hots/services. I thought I shall do it after the freeze, but its becoming too annoying. Thanks -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/SusmitShannigrahi ============================================= From dev at nigelj.com Sun Apr 27 06:09:21 2008 From: dev at nigelj.com (Nigel Jones) Date: Sun, 27 Apr 2008 18:09:21 +1200 (NZST) Subject: How much downtime do we afford for nagios? Message-ID: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> > Hi, Hi, > > For a few days false notification of nagios reduced. But it has increased > again. You sure? > > Looking at the /configs/system/nagios/services/template.cfg reveals > that it is configured as > max_check_attempt = 4 and retry_check_interval 1 for hosts > and > max_check_attempts = 3 and retry_check_interval 1. > > So if a service or host is unreachable for 3 or 4 mins, we get a > notification. (However most of the cases it is false positive, due to > congestion or others). Looking through my email, from what I can recall there are no false positives. xen6 had to be power-cycled which caused all the other collateral notifications. Just to put it into perspective... 1st notification: 0212UTC - Accounts down on .120-phx ... 5th notification: 0216UTC - UNKNOWN status on xen6 (NRPE: Unable to read output) ... 11/12th notifications: 0228UTC - Host Down - xen6/db2 & Starting 0233UTC - Host/service UP/Okay notifications According to my IRC logs xen6 went a bit haywire and had to be rebooted, so TBH I don't see what is false here. Yes congestion can cause some problems, but isn't that also a sign that stuff may need to be balanced better or given more processing/networking capacity. It's long enough to not detect every single VPN bloop, but it's also long enough to give an idea of problems. > > How about finding out a working delay which we can afford, if a > service or host is really down. How about 10 mins ? (5 attempt x 2 > mins?). IMO this is too long, also, it doesn't take that long for someone to SSH in and have a quick look, I don't speak for everyone, but I don't mind if I spend 2-5 minutes to check. > > Also we may list services/host which are critical and which are not. > That will help to define different notification period for the > different hots/services. > > I thought I shall do it after the freeze, but its becoming too annoying. Personally, I don't think anything should be done at the moment. - Nigel From thinklinux.ssh at gmail.com Sun Apr 27 06:22:58 2008 From: thinklinux.ssh at gmail.com (susmit shannigrahi) Date: Sun, 27 Apr 2008 11:52:58 +0530 Subject: How much downtime do we afford for nagios? In-Reply-To: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> Message-ID: > > So if a service or host is unreachable for 3 or 4 mins, we get a > > notification. (However most of the cases it is false positive, due to > > congestion or others). > Looking through my email, from what I can recall there are no false > positives. xen6 had to be power-cycled which caused all the other > collateral notifications. How long was it down? Why should a normal reboot will send 23 mails? Reboot is not any exceptional thing. Is it? An alert should be when its absolutely necessary... it should report only when xen6 comes up but a service does not come up.. What do you think? Thanks. -- Regards, Susmit. ============================================= ssh 0x86DD170A http://www.fedoraproject.org/wiki/SusmitShannigrahi ============================================= From dev at nigelj.com Sun Apr 27 07:00:44 2008 From: dev at nigelj.com (Nigel Jones) Date: Sun, 27 Apr 2008 19:00:44 +1200 (NZST) Subject: How much downtime do we afford for nagios? Message-ID: <50738.202.154.148.207.1209279644.squirrel@webmail.nigelj.com> >> > So if a service or host is unreachable for 3 or 4 mins, we get a >> > notification. (However most of the cases it is false positive, due to >> > congestion or others). >> Looking through my email, from what I can recall there are no false >> positives. xen6 had to be power-cycled which caused all the other >> collateral notifications. > > > How long was it down? Why should a normal reboot will send 23 mails? > Reboot is not any exceptional thing. Is it? > An alert should be when its absolutely necessary... > it should report only when xen6 comes up but a service does not come up.. > What do you think? > Thanks. Remembering that unresponsive and down are different things it looks like it went unresponsive ~0210 UTC (2-3 minutes before first email) - I *think* this might have just being domU's at that point, from IRC logs it looks like the dom0 was rebooted sometime around 0228 (potentially before hand I do not know). It's 1 email per checked item for down/up and I guess in perspective, it was quite big... IMO these reports are 'absolutely necessary' and I personally like to check it every now and then (especially after an outage like this to see if everything was back up (service/host overview on nagios web is handy for this). - Nigel > > > > -- > Regards, > Susmit. > > ============================================= > ssh > 0x86DD170A > http://www.fedoraproject.org/wiki/SusmitShannigrahi > ============================================= > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From luca at foppiano.org Sun Apr 27 08:43:41 2008 From: luca at foppiano.org (Luca Foppiano) Date: Sun, 27 Apr 2008 10:43:41 +0200 Subject: introduce myself In-Reply-To: References: <1209194505.3764.47.camel@sboing.byte-code.lan> Message-ID: <1209285821.3652.22.camel@sboing.byte-code.lan> On Sat, 2008-04-26 at 16:25 -0500, Mike McGrath wrote: > Welcome Luca, have you any experience with python and turbogears? I had experience only with python. About web applications I have experiences with java, but I can learn also TurboGears ;-) Luca -- Today is Boomtime, the 44th day of Discord in the YOLD 3174 From luca at foppiano.org Sun Apr 27 08:43:41 2008 From: luca at foppiano.org (Luca Foppiano) Date: Sun, 27 Apr 2008 10:43:41 +0200 Subject: introduce myself In-Reply-To: References: <1209194505.3764.47.camel@sboing.byte-code.lan> Message-ID: <1209285821.3652.22.camel@sboing.byte-code.lan> On Sat, 2008-04-26 at 16:25 -0500, Mike McGrath wrote: > Welcome Luca, have you any experience with python and turbogears? I had experience only with python. About web applications I have experiences with java, but I can learn also TurboGears ;-) Luca -- Today is Boomtime, the 44th day of Discord in the YOLD 3174 From kanarip at kanarip.com Sun Apr 27 11:01:58 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 27 Apr 2008 13:01:58 +0200 Subject: How much downtime do we afford for nagios? In-Reply-To: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> Message-ID: <48145D26.5010703@kanarip.com> Nigel Jones wrote: > Looking through my email, from what I can recall there are no false > positives. xen6 had to be power-cycled which caused all the other > collateral notifications. > Collateral notifications can be caught using service dependencies and parent hosts. Do we currently use any? Kind regards, Jeroen van Meeuwen -kanarip From dev at nigelj.com Sun Apr 27 12:43:03 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 28 Apr 2008 00:43:03 +1200 (NZST) Subject: How much downtime do we afford for nagios? In-Reply-To: <48145D26.5010703@kanarip.com> References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> <48145D26.5010703@kanarip.com> Message-ID: <57011.202.154.148.207.1209300183.squirrel@webmail.nigelj.com> On Sun, April 27, 2008 11:01 pm, Jeroen van Meeuwen wrote: > Nigel Jones wrote: >> Looking through my email, from what I can recall there are no false >> positives. xen6 had to be power-cycled which caused all the other >> collateral notifications. >> > > Collateral notifications can be caught using service dependencies and > parent hosts. Do we currently use any? I believe we do, but it wouldn't have helped in this case (I've done a bit more digging) Half the notifications came from the external nagios instance on noc2, while the xen6/db alerts came from the internal nagios instance. Another reason why I like the current setup and don't think we should change a thing :) Also, the UNKNOWN alerts weren't that bad, they were a precursor to the box having to restarted, only in this case was the up/down alerts a little useless. However, I'd sooner keep them as it because otherwise we run the risk of not noticing a box down immediately and get everyone under the moon asking "why can't I access fedoraproject.org... it's down your OS can't be that good". - Nigel > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From johnp at redhat.com Sun Apr 27 17:14:09 2008 From: johnp at redhat.com (John (J5) Palmieri) Date: Sun, 27 Apr 2008 13:14:09 -0400 Subject: Fedora Services API In-Reply-To: <481368AB.40803@gmail.com> References: <481368AB.40803@gmail.com> Message-ID: <1209316449.20499.6.camel@localhost.localdomain> On Sat, 2008-04-26 at 10:38 -0700, Toshio Kuratomi wrote: > Hey guys, I'm talking especially to the web app developers here, but I > also hope that other people will chime in with useful thoughts. > > As part of python-fedora, I've started documenting some standards for > Fedora Services. These will go hand in hand with documents on how to > use BaseClient that I am in the process of writing. These documents > will document how Fedora Services should be written rather than how they > are currently implemented. As such, I want to make sure everyone: > > 1) has a chance to review the document and make comments/changes before > the changesare integrated into BaseClient and people have to port to > things that are backwards incompatible. > > 2) can bring up other areas that need to be addressed. > > For instance, skvidal recently wrote a short client to the pkgdb that > can generate email aliases for packages (so package at packages.fp.o could > send mail to all the committers to a package). He had the following > comments to make: > > 1) It would be nice to have an introspection API to look at what methods > are available on a TG app and how to use them. > > 2) JSON data that is deeply nested sucks because objects are turned into > dictionaries so you have to write things like: > > package['listings']['F-8']['people']['toshio']['acls']['commit']['status'] > > to get the status of a person's acls on a package. > > I'd like to get other people's input on how to work on these and any > other issues before completing the next python-fedora so I can be sure > that I've got most of the incompatibilities in. Talking here and on IRC > is welcome. > > Here's the current version of the Fedora Services Documentation. What's > there should be complete. Addressing skvidal's concerns hasn't even > been stubbed out yet:: > http://tinyurl.com/52xmjw > > The BaseClient Documentation is still in heavy flux. It's here:: > http://tinyurl.com/4ww6v7 Nice, I need to fix up my stuff to use the BaseClient stuff. Right now I do it manually. We need to do the same type of documentation for writing widgets and come up with some standards for using JavaScript (such as use JQuery) for AJAXy stuff. I'll go over your docs in more detail on Monday and comment. What I would really like to see is this not just be a doc but be an example site much like the API documentation on the JQuery site. For instance for BaseClient, have working examples for each of the important API pieces which demonstrates how to use them and what to expect as output. -- John (J5) Palmieri From mmcgrath at redhat.com Sun Apr 27 17:16:13 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 27 Apr 2008 12:16:13 -0500 (CDT) Subject: How much downtime do we afford for nagios? In-Reply-To: References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> Message-ID: On Sun, 27 Apr 2008, susmit shannigrahi wrote: > > > So if a service or host is unreachable for 3 or 4 mins, we get a > > > notification. (However most of the cases it is false positive, due to > > > congestion or others). > > Looking through my email, from what I can recall there are no false > > positives. xen6 had to be power-cycled which caused all the other > > collateral notifications. > > > How long was it down? Why should a normal reboot will send 23 mails? > Reboot is not any exceptional thing. Is it? > An alert should be when its absolutely necessary... > it should report only when xen6 comes up but a service does not come up.. > What do you think? > Thanks. > A normal reboot shouldn't, but when its in a hung state, it takes a while before people can get to it. -Mike From mmcgrath at redhat.com Sun Apr 27 17:16:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 27 Apr 2008 12:16:38 -0500 (CDT) Subject: How much downtime do we afford for nagios? In-Reply-To: <48145D26.5010703@kanarip.com> References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> <48145D26.5010703@kanarip.com> Message-ID: On Sun, 27 Apr 2008, Jeroen van Meeuwen wrote: > Nigel Jones wrote: > > Looking through my email, from what I can recall there are no false > > positives. xen6 had to be power-cycled which caused all the other > > collateral notifications. > > > > Collateral notifications can be caught using service dependencies and parent > hosts. Do we currently use any? > There's a ticket open but no progress. -Mike From mmcgrath at redhat.com Sun Apr 27 17:21:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 27 Apr 2008 12:21:38 -0500 (CDT) Subject: How much downtime do we afford for nagios? In-Reply-To: <57011.202.154.148.207.1209300183.squirrel@webmail.nigelj.com> References: <49554.202.154.148.207.1209276561.squirrel@webmail.nigelj.com> <48145D26.5010703@kanarip.com> <57011.202.154.148.207.1209300183.squirrel@webmail.nigelj.com> Message-ID: On Mon, 28 Apr 2008, Nigel Jones wrote: > On Sun, April 27, 2008 11:01 pm, Jeroen van Meeuwen wrote: > > Nigel Jones wrote: > >> Looking through my email, from what I can recall there are no false > >> positives. xen6 had to be power-cycled which caused all the other > >> collateral notifications. > >> > > > > Collateral notifications can be caught using service dependencies and > > parent hosts. Do we currently use any? > I believe we do, but it wouldn't have helped in this case (I've done a bit > more digging) > > Half the notifications came from the external nagios instance on noc2, > while the xen6/db alerts came from the internal nagios instance. Another > reason why I like the current setup and don't think we should change a > thing :) > > Also, the UNKNOWN alerts weren't that bad, they were a precursor to the > box having to restarted, only in this case was the up/down alerts a little > useless. However, I'd sooner keep them as it because otherwise we run the > risk of not noticing a box down immediately and get everyone under the > moon asking "why can't I access fedoraproject.org... it's down your OS > can't be that good". One thing I would like implemented is event handlers. Some things (probably not this thing) could be handled automatically for us. -Mike From a.badger at gmail.com Sun Apr 27 19:40:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Apr 2008 12:40:59 -0700 Subject: Change Request: setup restart-memhogs on fas1/2 Message-ID: <4814D6CB.5030401@gmail.com> We have a script to restart TG apps on the app servers when their memory exceeds a customizable limit. We have this run on the app servers on alternate hours so that we don't take down all the load balanced copies of an app at the same time. This has proved useful for a few of our apps which have a tendency to grow until the box starts swapping. I'd like to set this up for fas1 and fas2 before we get to the hard change freeze. As an initial limit, I want to start with 1GB of rss before an app restarts. The present usage fas1 fas2 Memory on the box: 4096000 2048000 Memory usage after 1 day 21 hours: 728820 1005260 -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Sun Apr 27 20:12:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Apr 2008 13:12:09 -0700 Subject: Fedora Services API In-Reply-To: <20080427045929.GK12555@transam.devel.redhat.com> References: <481368AB.40803@gmail.com> <20080427045929.GK12555@transam.devel.redhat.com> Message-ID: <4814DE19.7060500@gmail.com> Jesus M. Rodriguez wrote: > On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: > [snip] > >> 2) JSON data that is deeply nested sucks because objects are turned into >> dictionaries so you have to write things like: >> >> package['listings']['F-8']['people']['toshio']['acls']['commit']['status'] >> >> to get the status of a person's acls on a package. > > When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) > where create_tree is an object creation method. The other option > is to change the depth of the object returned. > This sounds interesting. How do you tell which dictionaries can be turned into objects and which must remain dictionaries? Or does your create_tree method have special knowledge of the data being returned? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Sun Apr 27 20:10:49 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 27 Apr 2008 15:10:49 -0500 (CDT) Subject: Change Request: setup restart-memhogs on fas1/2 In-Reply-To: <4814D6CB.5030401@gmail.com> References: <4814D6CB.5030401@gmail.com> Message-ID: On Sun, 27 Apr 2008, Toshio Kuratomi wrote: > We have a script to restart TG apps on the app servers when their memory > exceeds a customizable limit. We have this run on the app servers on > alternate hours so that we don't take down all the load balanced copies of an > app at the same time. This has proved useful for a few of our apps which have > a tendency to grow until the box starts swapping. I'd like to set this up for > fas1 and fas2 before we get to the hard change freeze. > > As an initial limit, I want to start with 1GB of rss before an app restarts. > The present usage > > fas1 fas2 > Memory on the box: 4096000 2048000 > Memory usage after > 1 day 21 hours: 728820 1005260 > Thats fine, we should ultimately de-x86_64 these boxes but with everything else going on.... the mem-hog script will be best. +1 from me. -Mike From pavel.khardikov at gmail.com Sun Apr 27 20:39:38 2008 From: pavel.khardikov at gmail.com (Pavel Khardikov) Date: Mon, 28 Apr 2008 00:39:38 +0400 Subject: Introduction - Pavel Khardikov Message-ID: <4814E48A.5030809@gmail.com> Hello everybody, I'm Pavel Khardikov from the Kursk State University, Russia. I'm 22. I'm a first year student of postgraduate study. Graduated from the faculty of computer science and computer engineering. Speciality: administration software and information systems. My application have been accepted into Google Summer of Code 2008. I'm going to work on Pretty Web 2.0 Interfaces for Smolt. This is my first GSoC. I'm really happy about it. My mentor is Yaakov Nemoy. I want to help fedora project and open source, as well as to improve my skills and experiences. For more than 5 years, I worked as a system administrator for ISP (Internet Service Provider). I set up and supported servers and services (apache, nginx, tomcat, squid, exim, bind, postgresql, mysql, jabberd, pptpd, etc ...) administered RHEL, CentOS and Fedora. I have some experiences on OpenVZ and Xen infrastructure. I use Fedora 8 on my laptop. RHEL 5 or CentOS 5 is installed on my production servers basically. And moreover I like to programming. I know perl, python and web programming (XML, HTML/XHTML, CSS, cross-browser making-up). I like to design user interfaces. -- Best regards. Pavel Khardikov From jesusr at redhat.com Mon Apr 28 02:29:33 2008 From: jesusr at redhat.com (Jesus M. Rodriguez) Date: Sun, 27 Apr 2008 22:29:33 -0400 Subject: Fedora Services API In-Reply-To: <4814DE19.7060500@gmail.com> References: <481368AB.40803@gmail.com> <20080427045929.GK12555@transam.devel.redhat.com> <4814DE19.7060500@gmail.com> Message-ID: <20080428022933.GA19228@transam.devel.redhat.com> On Sun, Apr 27, 2008 at 01:12:09PM -0700, Toshio Kuratomi wrote: > Jesus M. Rodriguez wrote: >> On Sat, Apr 26, 2008 at 10:38:51AM -0700, Toshio Kuratomi wrote: >> [snip] >> >>> 2) JSON data that is deeply nested sucks because objects are turned into >>> dictionaries so you have to write things like: >>> >>> package['listings']['F-8']['people']['toshio']['acls']['commit']['status'] >>> >>> to get the status of a person's acls on a package. >> >> When writing zmugfs I used simplejson.loads(rsp, object_hook=create_tree) >> where create_tree is an object creation method. The other option >> is to change the depth of the object returned. >> > This sounds interesting. How do you tell which dictionaries can be turned > into objects and which must remain dictionaries? Or does your create_tree > method have special knowledge of the data being returned? The create_tree in this example knows that it is building a Tree. I also have a create_album which creates an Album. It isn't generic at all, but it does offer a way to return objects from json responses quite easily. -- jesus m. rodriguez | jesusr at redhat.com sr. software engineer | irc: zeus red hat network | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +-------------------------------------------+ | "Those who cannot learn from history | | are doomed to repeat it." | | -- George Santayana | +-------------------------------------------+ From mmcgrath at redhat.com Mon Apr 28 13:31:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Apr 2008 08:31:31 -0500 (CDT) Subject: Introduction - Pavel Khardikov In-Reply-To: <4814E48A.5030809@gmail.com> References: <4814E48A.5030809@gmail.com> Message-ID: On Mon, 28 Apr 2008, Pavel Khardikov wrote: > Hello everybody, > > I'm Pavel Khardikov from the Kursk State University, Russia. I'm 22. I'm a > first year student of postgraduate study. > Graduated from the faculty of computer science and computer engineering. > Speciality: administration software and information systems. > > My application have been accepted into Google Summer of Code 2008. I'm going > to work on Pretty Web 2.0 Interfaces for Smolt. > This is my first GSoC. I'm really happy about it. My mentor is Yaakov Nemoy. > Sweet! I've seen your markups and look forward to the outcome. > I want to help fedora project and open source, as well as to improve my skills > and experiences. > > For more than 5 years, I worked as a system administrator for ISP (Internet > Service Provider). I set up and supported servers and services (apache, nginx, > tomcat, squid, exim, bind, postgresql, mysql, jabberd, pptpd, etc ...) > administered RHEL, CentOS and Fedora. I have some experiences on OpenVZ and > Xen infrastructure. > > I use Fedora 8 on my laptop. RHEL 5 or CentOS 5 is installed on my production > servers basically. > > And moreover I like to programming. > I know perl, python and web programming (XML, HTML/XHTML, CSS, cross-browser > making-up). > I like to design user interfaces. > Welcome aboard Pavel! Let us know if you need anything. -Mike From mmcgrath at redhat.com Mon Apr 28 13:51:00 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Apr 2008 08:51:00 -0500 (CDT) Subject: Change freeze tomorrow! Message-ID: Just a reminder... The real change freze starts tomorrow. If you've got something to do... DO IT! :) -Mike From dennis at ausil.us Mon Apr 28 14:02:55 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 28 Apr 2008 09:02:55 -0500 Subject: Change freeze tomorrow! In-Reply-To: References: Message-ID: <200804280902.59993.dennis@ausil.us> On Monday 28 April 2008, Mike McGrath wrote: > Just a reminder... The real change freze starts tomorrow. If you've got > something to do... DO IT! :) I did just update the epel mock configs. we really have RHEL updates in the epel buildroots now. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Mon Apr 28 18:03:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 28 Apr 2008 13:03:46 -0500 (CDT) Subject: get.fedoraproject.org -> fedoraproject.org/get-fedora Message-ID: There's been a request to redirect get.fedoraproject.org to /get-fedora (pauls request) Can I get a +1? -Mike From dennis at ausil.us Mon Apr 28 18:15:55 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 28 Apr 2008 13:15:55 -0500 Subject: get.fedoraproject.org -> fedoraproject.org/get-fedora In-Reply-To: References: Message-ID: <200804281315.56750.dennis@ausil.us> On Monday 28 April 2008, Mike McGrath wrote: > There's been a request to redirect get.fedoraproject.org to /get-fedora > (pauls request) > > Can I get a +1? > > -Mike +1 From a.badger at gmail.com Mon Apr 28 18:17:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Apr 2008 11:17:45 -0700 Subject: get.fedoraproject.org -> fedoraproject.org/get-fedora In-Reply-To: References: Message-ID: <481614C9.1080205@gmail.com> Mike McGrath wrote: > There's been a request to redirect get.fedoraproject.org to /get-fedora > (pauls request) > > Can I get a +1? > +1 Reasonably safe. Useful to end users. -Toshio From skvidal at fedoraproject.org Mon Apr 28 18:21:30 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Apr 2008 14:21:30 -0400 Subject: get.fedoraproject.org -> fedoraproject.org/get-fedora In-Reply-To: References: Message-ID: <1209406890.7934.7.camel@cutter> On Mon, 2008-04-28 at 13:03 -0500, Mike McGrath wrote: > There's been a request to redirect get.fedoraproject.org to /get-fedora > (pauls request) > > Can I get a +1? > +1 -sv From angel.fedora at gmail.com Mon Apr 28 18:26:23 2008 From: angel.fedora at gmail.com (Angel) Date: Tue, 29 Apr 2008 00:26:23 +0600 Subject: get.fedoraproject.org -> fedoraproject.org/get-fedora In-Reply-To: <200804281315.56750.dennis@ausil.us> References: <200804281315.56750.dennis@ausil.us> Message-ID: <481616CF.8060901@gmail.com> Just I hit to my.fedoraproject.org, but i didn't reach to that page. Do you think, it's related to get.fedoraproject.org? Or what are you talking about? I am asking this, because, when I hit that page, a while later, i got this mail!!!! Dennis Gilmore wrote: > On Monday 28 April 2008, Mike McGrath wrote: > >> There's been a request to redirect get.fedoraproject.org to /get-fedora >> (pauls request) >> >> Can I get a +1? >> >> -Mike >> > +1 > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > From tchung at fedoraproject.org Tue Apr 29 06:57:12 2008 From: tchung at fedoraproject.org (Thomas Chung) Date: Mon, 28 Apr 2008 23:57:12 -0700 Subject: UnicodeEncodeError on Tours/Fedora9 Message-ID: <369bce3b0804282357k153f4f53xe45695366d5f97ec@mail.gmail.com> Hello Infrastructure Team, I just got "UnicodeEncodeError" on Tours/Fedora9 [1] http://fedoraproject.org/wiki/Infrastructure/SOP/wiki#UnicodeEncodeError [2] http://fedoraproject.org/wiki/Tours/Fedora9 Thank you. -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From paulo.banon at googlemail.com Tue Apr 29 07:23:29 2008 From: paulo.banon at googlemail.com (Paulo Santos) Date: Tue, 29 Apr 2008 09:23:29 +0200 Subject: UnicodeEncodeError on Tours/Fedora9 In-Reply-To: <369bce3b0804282357k153f4f53xe45695366d5f97ec@mail.gmail.com> References: <369bce3b0804282357k153f4f53xe45695366d5f97ec@mail.gmail.com> Message-ID: <7a41c4bc0804290023u77f1946dwc8c8cdec492ded64@mail.gmail.com> Hi Thomas, This one is fixed. Thanks for reporting it :) As a side note, i fixed several other unicode errors present on the edit-log Paulo On Tue, Apr 29, 2008 at 8:57 AM, Thomas Chung wrote: > Hello Infrastructure Team, > I just got "UnicodeEncodeError" on Tours/Fedora9 > > [1] > http://fedoraproject.org/wiki/Infrastructure/SOP/wiki#UnicodeEncodeError > [2] http://fedoraproject.org/wiki/Tours/Fedora9 > > Thank you. > -- > Thomas Chung > http://fedoraproject.org/wiki/ThomasChung > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tchung at fedoraproject.org Tue Apr 29 07:25:28 2008 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 29 Apr 2008 00:25:28 -0700 Subject: UnicodeEncodeError on Tours/Fedora9 In-Reply-To: <7a41c4bc0804290023u77f1946dwc8c8cdec492ded64@mail.gmail.com> References: <369bce3b0804282357k153f4f53xe45695366d5f97ec@mail.gmail.com> <7a41c4bc0804290023u77f1946dwc8c8cdec492ded64@mail.gmail.com> Message-ID: <369bce3b0804290025q2cddb6b7pe78fd42e88741bf5@mail.gmail.com> 2008/4/29 Paulo Santos : > Hi Thomas, > > This one is fixed. > Thanks for reporting it :) > > As a side note, i fixed several other unicode errors present on the edit-log > > > Paulo Thank you for your quick response. :) Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From mmcgrath at redhat.com Tue Apr 29 14:07:20 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 09:07:20 -0500 (CDT) Subject: Change request Message-ID: The *real* freeze has started. I'd like to build a different box for the secondary.fedoraproject.org bits. Initial space requirements were off, I'd like to move the bits to a host in PHX. This will require kicking a new host with enough storage. Possibly wiping the old /mnt/koji share (I'll wait for approval from jesse on that) Risk: low This request relates to the F9 release because secondary arch needs a place to host the ia64 bits. Can I get a +1? From notting at redhat.com Tue Apr 29 14:21:52 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Apr 2008 10:21:52 -0400 Subject: Change request In-Reply-To: References: Message-ID: <20080429142152.GD21739@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > > The *real* freeze has started. > > I'd like to build a different box for the secondary.fedoraproject.org > bits. Initial space requirements were off, I'd like to move the bits to a > host in PHX. This will require kicking a new host with enough storage. > Possibly wiping the old /mnt/koji share (I'll wait for approval from jesse > on that) > > Risk: low > > This request relates to the F9 release because secondary arch needs a > place to host the ia64 bits. > > Can I get a +1? Assuming we're not going to run out of space once we have 2/3/4 secondary arches, +1. Bill From mmcgrath at redhat.com Tue Apr 29 14:21:34 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 09:21:34 -0500 (CDT) Subject: Change request In-Reply-To: <20080429142152.GD21739@nostromo.devel.redhat.com> References: <20080429142152.GD21739@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Apr 2008, Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > > > > The *real* freeze has started. > > > > I'd like to build a different box for the secondary.fedoraproject.org > > bits. Initial space requirements were off, I'd like to move the bits to a > > host in PHX. This will require kicking a new host with enough storage. > > Possibly wiping the old /mnt/koji share (I'll wait for approval from jesse > > on that) > > > > Risk: low > > > > This request relates to the F9 release because secondary arch needs a > > place to host the ia64 bits. > > > > Can I get a +1? > > Assuming we're not going to run out of space once we have 2/3/4 secondary > arches, +1. > Actually I have no space requirements for anything other then ia64 right now so I cannot say whether we will or won't run out of space for the other arches. -Mike From notting at redhat.com Tue Apr 29 14:29:08 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Apr 2008 10:29:08 -0400 Subject: Change request In-Reply-To: References: <20080429142152.GD21739@nostromo.devel.redhat.com> Message-ID: <20080429142908.GE21739@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > > Assuming we're not going to run out of space once we have 2/3/4 secondary > > arches, +1. > > Actually I have no space requirements for anything other then ia64 right > now so I cannot say whether we will or won't run out of space for the > other arches. Do we want to spec out for this build (ia64 requirements) x 3? Do we have that sort of space available? Bill From mmcgrath at redhat.com Tue Apr 29 14:28:22 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 09:28:22 -0500 (CDT) Subject: Change request In-Reply-To: <20080429142908.GE21739@nostromo.devel.redhat.com> References: <20080429142152.GD21739@nostromo.devel.redhat.com> <20080429142908.GE21739@nostromo.devel.redhat.com> Message-ID: On Tue, 29 Apr 2008, Bill Nottingham wrote: > Mike McGrath (mmcgrath at redhat.com) said: > > > Assuming we're not going to run out of space once we have 2/3/4 secondary > > > arches, +1. > > > > Actually I have no space requirements for anything other then ia64 right > > now so I cannot say whether we will or won't run out of space for the > > other arches. > > Do we want to spec out for this build (ia64 requirements) x 3? Do we > have that sort of space available? > Not sure if we do or not. Dennis, is ia64 the benchmark for secondary archs? Can we just multiply it * 3? Also what are the updates requirements / release for these archs? -Mike From mmcgrath at redhat.com Tue Apr 29 15:11:15 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 10:11:15 -0500 (CDT) Subject: Koji backups Message-ID: We now have all the tapes we need to do koji backups of /mnt/koji. Can I get a +1? -Mike From notting at redhat.com Tue Apr 29 15:20:17 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Apr 2008 11:20:17 -0400 Subject: Koji backups In-Reply-To: References: Message-ID: <20080429152017.GB25280@nostromo.devel.redhat.com> Mike McGrath (mmcgrath at redhat.com) said: > We now have all the tapes we need to do koji backups of /mnt/koji. Can I > get a +1? Backups are good. +1 Bill From jkeating at j2solutions.net Tue Apr 29 16:41:53 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 29 Apr 2008 09:41:53 -0700 Subject: Koji backups In-Reply-To: References: Message-ID: <37473E8A-FE00-43F0-9D44-E62EFC540360@j2solutions.net> On Apr 29, 2008, at 8:11, Mike McGrath wrote: > We now have all the tapes we need to do koji backups of /mnt/koji. > Can I > get a +1? > > -Mike > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list +1. Although if the backup starts to make builds pile up I want to be able to suspend it for a bit. --jes From dennis at ausil.us Tue Apr 29 19:04:07 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 29 Apr 2008 14:04:07 -0500 Subject: Koji backups In-Reply-To: References: Message-ID: <200804291404.07589.dennis@ausil.us> On Tuesday 29 April 2008, Mike McGrath wrote: > We now have all the tapes we need to do koji backups of /mnt/koji. Can I > get a +1? +1 and the backup has started Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dennis at ausil.us Tue Apr 29 19:03:34 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 29 Apr 2008 14:03:34 -0500 Subject: Change request In-Reply-To: References: <20080429142908.GE21739@nostromo.devel.redhat.com> Message-ID: <200804291403.39205.dennis@ausil.us> On Tuesday 29 April 2008, Mike McGrath wrote: > On Tue, 29 Apr 2008, Bill Nottingham wrote: > > Mike McGrath (mmcgrath at redhat.com) said: > > > > Assuming we're not going to run out of space once we have 2/3/4 > > > > secondary arches, +1. > > > > > > Actually I have no space requirements for anything other then ia64 > > > right now so I cannot say whether we will or won't run out of space for > > > the other arches. > > > > Do we want to spec out for this build (ia64 requirements) x 3? Do we > > have that sort of space available? > > Not sure if we do or not. Dennis, is ia64 the benchmark for secondary > archs? Can we just multiply it * 3? Also what are the updates > requirements / release for these archs? +1 from me as far as requirements sparc/sparc64 will be ~ same as ppc/ppc64 ia64, alpha, arm should be close to i386 s390 im not sure but im guessing similar to sparc unless they only build for s390x and drop support for s390 though alpha, arm, and s390 lag behind sparc which is behind ia64. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Tue Apr 29 19:16:53 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 29 Apr 2008 15:16:53 -0400 Subject: change request: archive.fp.o Message-ID: <1209496614.8968.86.camel@cutter> Hey, We've got the disk and box up together for archive.fp.o thanks to the great folks at bu.edu. I'd like to get an okay to add the host and get it ready to be archive.fp.o +1, please? -sv -- I only speak for me. From notting at redhat.com Tue Apr 29 19:47:24 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 29 Apr 2008 15:47:24 -0400 Subject: change request: archive.fp.o In-Reply-To: <1209496614.8968.86.camel@cutter> References: <1209496614.8968.86.camel@cutter> Message-ID: <20080429194724.GD11131@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > Hey, > We've got the disk and box up together for archive.fp.o thanks to the > great folks at bu.edu. I'd like to get an okay to add the host and get > it ready to be archive.fp.o > > +1, please? +1 to add and get it ready. -1 to any content migrartion. Which, now that I look, you didn't actually ask for... Bill From mmcgrath at redhat.com Tue Apr 29 19:49:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 14:49:06 -0500 (CDT) Subject: Change request In-Reply-To: <200804291403.39205.dennis@ausil.us> References: <20080429142908.GE21739@nostromo.devel.redhat.com> <200804291403.39205.dennis@ausil.us> Message-ID: On Tue, 29 Apr 2008, Dennis Gilmore wrote: > On Tuesday 29 April 2008, Mike McGrath wrote: > > On Tue, 29 Apr 2008, Bill Nottingham wrote: > > > Mike McGrath (mmcgrath at redhat.com) said: > > > > > Assuming we're not going to run out of space once we have 2/3/4 > > > > > secondary arches, +1. > > > > > > > > Actually I have no space requirements for anything other then ia64 > > > > right now so I cannot say whether we will or won't run out of space for > > > > the other arches. > > > > > > Do we want to spec out for this build (ia64 requirements) x 3? Do we > > > have that sort of space available? > > > > Not sure if we do or not. Dennis, is ia64 the benchmark for secondary > > archs? Can we just multiply it * 3? Also what are the updates > > requirements / release for these archs? > +1 from me > > as far as requirements sparc/sparc64 will be ~ same as ppc/ppc64 ia64, > alpha, arm should be close to i386 s390 im not sure but im guessing > similar to sparc unless they only build for s390x and drop support for s390 > > though alpha, arm, and s390 lag behind sparc which is behind ia64. > So the actual number we should be using to reserve space for an arch for a release is..? I really really really need someone to find that number and commit to it and its essential that the number be correct. We have done a horrid job of guessing how much space we need for things and its caused a lot of needless headaches. It's not easy to guess how much space we need. There's a lot of parts involved, especially when you start talking about isos and updates. So lets not guess. Lets do some research and get that number. -Mike From skvidal at fedoraproject.org Tue Apr 29 19:54:22 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 29 Apr 2008 15:54:22 -0400 Subject: change request: archive.fp.o In-Reply-To: <20080429194724.GD11131@nostromo.devel.redhat.com> References: <1209496614.8968.86.camel@cutter> <20080429194724.GD11131@nostromo.devel.redhat.com> Message-ID: <1209498862.8968.90.camel@cutter> On Tue, 2008-04-29 at 15:47 -0400, Bill Nottingham wrote: > seth vidal (skvidal at fedoraproject.org) said: > > Hey, > > We've got the disk and box up together for archive.fp.o thanks to the > > great folks at bu.edu. I'd like to get an okay to add the host and get > > it ready to be archive.fp.o > > > > +1, please? > > +1 to add and get it ready. > -1 to any content migrartion. Which, now that I look, you didn't actually > ask for... No, No content migration. I might pre-sync some data over there. Though that's not harmful to anything existing afaik. -sv From mmcgrath at redhat.com Tue Apr 29 19:56:04 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Apr 2008 14:56:04 -0500 (CDT) Subject: change request: archive.fp.o In-Reply-To: <1209498862.8968.90.camel@cutter> References: <1209496614.8968.86.camel@cutter> <20080429194724.GD11131@nostromo.devel.redhat.com> <1209498862.8968.90.camel@cutter> Message-ID: On Tue, 29 Apr 2008, seth vidal wrote: > On Tue, 2008-04-29 at 15:47 -0400, Bill Nottingham wrote: > > seth vidal (skvidal at fedoraproject.org) said: > > > Hey, > > > We've got the disk and box up together for archive.fp.o thanks to the > > > great folks at bu.edu. I'd like to get an okay to add the host and get > > > it ready to be archive.fp.o > > > > > > +1, please? > > > > +1 to add and get it ready. > > -1 to any content migrartion. Which, now that I look, you didn't actually > > ask for... > > No, No content migration. I might pre-sync some data over there. Though > that's not harmful to anything existing afaik. > +1 to pre-syncing some content. We've got 194G free. Which, according to: http://download.fedora.redhat.com/pub/DIRECTORY_SIZES.txt Is enough for 2 more preview releases. Jesse, can you confirm our final shipping will fit into the space we have avaialble? -Mike From mmcgrath at redhat.com Wed Apr 30 07:09:24 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Apr 2008 02:09:24 -0500 (CDT) Subject: ** PROBLEM alert - 209.132.176.98-phx/koji is CRITICAL ** (fwd) Message-ID: Not sure what just happened. The db server freaked out for about a half hour: Time (UTC) runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 06:30:01 AM 0 157 1.00 1.27 1.70 06:40:06 AM 0 275 62.13 26.97 11.17 06:50:07 AM 0 270 52.43 55.90 35.88 07:00:06 AM 1 235 36.48 43.22 39.26 07:10:01 AM 0 169 1.96 17.56 29.83 Time (UTC) pswpin/s pswpout/s 06:40:06 AM 0.00 0.07 06:50:07 AM 717.03 803.21 07:00:06 AM 381.30 46.78 07:10:01 AM 82.42 0.67 By the time I got the alerts and got to my workstation everything was fine. Something to keep an eye on.. -Mike ---------- Forwarded message ---------- Date: Wed, 30 Apr 2008 06:42:08 GMT From: Nagios Monitoring User To: sysadmin-members at fedoraproject.org Subject: ** PROBLEM alert - 209.132.176.98-phx/koji is CRITICAL ** ***** Nagios ***** Notification Type: PROBLEM Service: koji Host: 209.132.176.98-phx Address: 209.132.176.98 State: CRITICAL Date/Time: Wed Apr 30 06:42:08 UTC 2008 Additional Info: CRITICAL - Socket timeout after 29 seconds From mmcgrath at redhat.com Wed Apr 30 14:27:27 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Apr 2008 09:27:27 -0500 (CDT) Subject: Outage reminder (this weekend) Message-ID: https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00023.html The heaviest hit will be that db2 is going to have to be down this whole time which controls many of our apps. Especially accounts. -Mike From skvidal at fedoraproject.org Wed Apr 30 14:43:01 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 30 Apr 2008 10:43:01 -0400 Subject: Outage reminder (this weekend) In-Reply-To: References: Message-ID: <1209566581.8968.124.camel@cutter> On Wed, 2008-04-30 at 09:27 -0500, Mike McGrath wrote: > https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00023.html > > The heaviest hit will be that db2 is going to have to be down this whole > time which controls many of our apps. Especially accounts. > Is there a good reason not to shut it all down manually so we don't have to deal with a 100000 messages from cron complaining about it? -sv From ricky at fedoraproject.org Wed Apr 30 14:51:12 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 30 Apr 2008 10:51:12 -0400 Subject: Change Request: Modify apache config on publictest10 for Transifex testing Message-ID: <20080430145112.GF6256@Max> I'd like to modify the Apache configs on publictest10 so that Diego can have a separate test instance of Transifex running. The change would look something like this (in /etc/httpd/conf.d/publictest10.fedoraproject.org/transifex.conf): ProxyPass /submit-diegobz http://localhost:8089/submit-diegobz ProxyPassReverse /submit-diegobz http://localhost:8089/submit-diegobz Header unset Set-Cookie Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Apr 30 14:59:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Apr 2008 09:59:31 -0500 (CDT) Subject: Change Request: Modify apache config on publictest10 for Transifex testing In-Reply-To: <20080430145112.GF6256@Max> References: <20080430145112.GF6256@Max> Message-ID: On Wed, 30 Apr 2008, Ricky Zhou wrote: > I'd like to modify the Apache configs on publictest10 so that Diego can > have a separate test instance of Transifex running. The change would > look something like this (in > /etc/httpd/conf.d/publictest10.fedoraproject.org/transifex.conf): > > ProxyPass /submit-diegobz http://localhost:8089/submit-diegobz > ProxyPassReverse /submit-diegobz http://localhost:8089/submit-diegobz > > > Header unset Set-Cookie > > For the next change freeze I think we'll have a more mature policy that takes things like this into account. By F10 we should have a complete separation of distribution, build, support and value added services. This will allow us to easily and quickly determine what machines are in Fedora's critical path. For now though I say +1 to this change. Very very low risk. -Mike From dennis at ausil.us Wed Apr 30 14:55:45 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 30 Apr 2008 09:55:45 -0500 Subject: Change Request: Modify apache config on publictest10 for Transifex testing In-Reply-To: <20080430145112.GF6256@Max> References: <20080430145112.GF6256@Max> Message-ID: <200804300955.52805.dennis@ausil.us> On Wednesday 30 April 2008, Ricky Zhou wrote: > I'd like to modify the Apache configs on publictest10 so that Diego can > have a separate test instance of Transifex running. The change would > look something like this (in > /etc/httpd/conf.d/publictest10.fedoraproject.org/transifex.conf): > > ProxyPass /submit-diegobz http://localhost:8089/submit-diegobz > ProxyPassReverse /submit-diegobz http://localhost:8089/submit-diegobz > > > Header unset Set-Cookie > > > Thanks, > Ricky +! from me Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Wed Apr 30 14:57:45 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Apr 2008 09:57:45 -0500 (CDT) Subject: Outage reminder (this weekend) In-Reply-To: <1209566581.8968.124.camel@cutter> References: <1209566581.8968.124.camel@cutter> Message-ID: On Wed, 30 Apr 2008, seth vidal wrote: > On Wed, 2008-04-30 at 09:27 -0500, Mike McGrath wrote: > > https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00023.html > > > > The heaviest hit will be that db2 is going to have to be down this whole > > time which controls many of our apps. Especially accounts. > > > > Is there a good reason not to shut it all down manually so we don't have > to deal with a 100000 messages from cron complaining about it? > We'll be shutting almost everything down manually (especially things connected via iscsi) but I had thought about also shutting down cron on a couple of boxes that will remain up (like the website, mirrorlist boxes, hosted, torrent, people, planet, dns, etc) -Mike From ricky at fedoraproject.org Wed Apr 30 17:07:05 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 30 Apr 2008 13:07:05 -0400 Subject: Change Request: Test unicode fixes on transifex on app4 Message-ID: <20080430170704.GH6256@Max> Recently, translators with unicode characters in their name have been unable to commit to some modules in Transifex. Since these translations need to be submitted for the F9 release and I haven't been able to reproduce on a testing instance, I'd like to try a fix on the production version on app4. This should be pretty low risk (and affect nothing but transifex for a few minutes). The change looks something like: command = [arg.encode('utf8') for arg in command] after line 127 in /srv/tg/transifex/transifex/util.py. If this doesn't work out, I will have to look for other problems (which should once again only affect transifex for a bit). Does this sound safe? Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Apr 30 18:06:37 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 30 Apr 2008 13:06:37 -0500 (CDT) Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <20080430170704.GH6256@Max> References: <20080430170704.GH6256@Max> Message-ID: On Wed, 30 Apr 2008, Ricky Zhou wrote: > Recently, translators with unicode characters in their name have been > unable to commit to some modules in Transifex. Since these translations > need to be submitted for the F9 release and I haven't been able to > reproduce on a testing instance, I'd like to try a fix on the production > version on app4. This should be pretty low risk (and affect nothing but > transifex for a few minutes). The change looks something like: > > command = [arg.encode('utf8') for arg in command] > > after line 127 in /srv/tg/transifex/transifex/util.py. If this doesn't > work out, I will have to look for other problems (which should once > again only affect transifex for a bit). > > Does this sound safe? > Not doing this means some translations for some F9 content won't get translated? if thats the case then I'd say +1. Seems low risk and has a positive, direct outsomce on F9. -Mike From ivazqueznet at gmail.com Wed Apr 30 18:12:01 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 30 Apr 2008 14:12:01 -0400 Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <20080430170704.GH6256@Max> References: <20080430170704.GH6256@Max> Message-ID: <1209579121.24162.17.camel@ignacio.lan> On Wed, 2008-04-30 at 13:07 -0400, Ricky Zhou wrote: > Recently, translators with unicode characters in their name have been > unable to commit to some modules in Transifex. Since these translations > need to be submitted for the F9 release and I haven't been able to > reproduce on a testing instance, I'd like to try a fix on the production > version on app4. This should be pretty low risk (and affect nothing but > transifex for a few minutes). The change looks something like: > > command = [arg.encode('utf8') for arg in command] > > after line 127 in /srv/tg/transifex/transifex/util.py. If this doesn't > work out, I will have to look for other problems (which should once > again only affect transifex for a bit). > > Does this sound safe? -1 I'm not convinced that this shotgun approach is best. I recommend applying the less-invasive attached patch and figuring out what's wrong first. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: tfx-util.patch Type: text/x-patch Size: 493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Apr 30 18:14:52 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Apr 2008 11:14:52 -0700 Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <20080430170704.GH6256@Max> References: <20080430170704.GH6256@Max> Message-ID: <4818B71C.3010906@gmail.com> Ricky Zhou wrote: > Recently, translators with unicode characters in their name have been > unable to commit to some modules in Transifex. Since these translations > need to be submitted for the F9 release and I haven't been able to > reproduce on a testing instance, I'd like to try a fix on the production > version on app4. This should be pretty low risk (and affect nothing but > transifex for a few minutes). The change looks something like: > > command = [arg.encode('utf8') for arg in command] > > after line 127 in /srv/tg/transifex/transifex/util.py. If this doesn't > work out, I will have to look for other problems (which should once > again only affect transifex for a bit). > > Does this sound safe? > Sounds safe. But after looking at this on IRC I'm not sure that addresses the actual problem (it might be treating a symptom.) Can we get a bit of logging into there so we can see what's going on? I'd like to know what the value of the arguments being passed to subprocess.Popen() is and also what their types are. -Toshio From ricky at fedoraproject.org Wed Apr 30 18:18:04 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 30 Apr 2008 14:18:04 -0400 Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <1209579121.24162.17.camel@ignacio.lan> References: <20080430170704.GH6256@Max> <1209579121.24162.17.camel@ignacio.lan> Message-ID: <20080430181804.GI6256@Max> On 2008-04-30 02:12:01 PM, Ignacio Vazquez-Abrams wrote: > I'm not convinced that this shotgun approach is best. I recommend > applying the less-invasive attached patch and figuring out what's wrong > first. All right then, we're going to try and get a bit more information about where the problem is coming from first (adding those debugging statements now). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Wed Apr 30 18:31:59 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 30 Apr 2008 14:31:59 -0400 Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <20080430181804.GI6256@Max> References: <20080430170704.GH6256@Max> <1209579121.24162.17.camel@ignacio.lan> <20080430181804.GI6256@Max> Message-ID: <1209580319.24162.20.camel@ignacio.lan> On Wed, 2008-04-30 at 14:18 -0400, Ricky Zhou wrote: > On 2008-04-30 02:12:01 PM, Ignacio Vazquez-Abrams wrote: > > I'm not convinced that this shotgun approach is best. I recommend > > applying the less-invasive attached patch and figuring out what's wrong > > first. > All right then, we're going to try and get a bit more information about > where the problem is coming from first (adding those debugging > statements now). This patch should fix it based on discussion in IRC. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: tfx-model.patch Type: text/x-patch Size: 618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ricky at fedoraproject.org Wed Apr 30 19:10:09 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Wed, 30 Apr 2008 15:10:09 -0400 Subject: Change Request: Test unicode fixes on transifex on app4 In-Reply-To: <1209580319.24162.20.camel@ignacio.lan> References: <20080430170704.GH6256@Max> <1209579121.24162.17.camel@ignacio.lan> <20080430181804.GI6256@Max> <1209580319.24162.20.camel@ignacio.lan> Message-ID: <20080430191009.GJ6256@Max> On 2008-04-30 02:31:59 PM, Ignacio Vazquez-Abrams wrote: > On Wed, 2008-04-30 at 14:18 -0400, Ricky Zhou wrote: > > On 2008-04-30 02:12:01 PM, Ignacio Vazquez-Abrams wrote: > > > I'm not convinced that this shotgun approach is best. I recommend > > > applying the less-invasive attached patch and figuring out what's wrong > > > first. > > All right then, we're going to try and get a bit more information about > > where the problem is coming from first (adding those debugging > > statements now). > > This patch should fix it based on discussion in IRC. We ended up encoding all of the arguments. From what we concluded, this might be a python 2.4 bug, so this was the most general way to fix it (since other code uses run_command as well, and we want to encode as late as possible). Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ianweller at gmail.com Wed Apr 30 22:02:11 2008 From: ianweller at gmail.com (Ian Weller) Date: Wed, 30 Apr 2008 17:02:11 -0500 (CDT) Subject: change request: mediawiki CSS (publictest1) Message-ID: I would like to make a very minor change to publictest1. MediaWiki is running on that, and the CSS it is using applies black borders to all tables, which looks really ugly. The request is to change the template and lighten the border color; all will be done within the MediaWiki directory. -- ian From a.badger at gmail.com Wed Apr 30 22:16:54 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Apr 2008 15:16:54 -0700 Subject: change request: mediawiki CSS (publictest1) In-Reply-To: References: Message-ID: <4818EFD6.3010100@gmail.com> Ian Weller wrote: > I would like to make a very minor change to publictest1. MediaWiki is > running on that, and the CSS it is using applies black borders to all > tables, which looks really ugly. The request is to change the template > and lighten the border color; all will be done within the MediaWiki > directory. > +1. -Toshio