infrastructure July 2010

infrastructure@lists.fedoraproject.org

40 participants
47 discussions

FIG request
by touruni touruni 28 Jul '10

28 Jul '10

All, Per initiation procedure outlined here: http://fedoraproject.org/wiki/Infrastructure/GettingSponsored Will someone be kind enough to sponsor this semi-young lad who has: - 10 Years of experience in IT - 1 Year of Python programming - 3 Year of RHEL Administration - RT/Nagios/The Grinder/Xen/Kickstart/Plone/Django I am interested the items listed below : Python Script writers and automators Virtualization Building and build environments Ideally i would like to work on all things that utilizes python. I am looking to develope my python programming skills. Whether it be a program that needs to written or a script or updating something that is python. I am applying from Sacramento, California / PST. I am interested in working on the team because I have a passion to learn. I want to sharpen my skills and collaborating with others who have the same passion. Best, Sophon Im <http://fedoraproject.org/wiki/Infrastructure/GettingSponsored>

1 0

New guy
by Carlos "casep" Sepulveda 27 Jul '10

27 Jul '10

Hi! I'm Carlos from Chile. I'm a 10 years linux user and currently full time AIX/RedHat sysadmin. I'm interested in monitoring and/or configuration setups versioning/control (I've never used git, only cvs and svn, shame on my!) I hope could help, soon. Regards -- "My name is Ozymandias, king of kings: Look on my works, ye Mighty, and despair!" Percy Bysshe Shelley http://sites.google.com/site/carlossepulveda

2 1

Upcoming Fedora 14 Tasks
by John Poelstra 26 Jul '10

26 Jul '10

Start End Name Tue 03-Aug Tue 17-Aug Alpha Infrastructure Change Freeze Have you found something that is working really well in your schedule? Or maybe you've found something you believe would work better in the future? Update the schedule retrospective page now to capture all of the important details as they happen: https://fedoraproject.org/wiki/Fedora_14_Schedule_Retrospective

1 0

Re: Fwd: PROBLEM: koji01.phx2.fedoraproject.org/koji is CRITICAL
by Dennis Gilmore 24 Jul '10

24 Jul '10

Sure that's fine "Stephen John Smoogen" <smooge(a)gmail.com> wrote: >On Sat, Jul 24, 2010 at 07:01, Dennis Gilmore <dennis(a)ausil.us> wrote: >> All the rhel5 builders are disabled until i can rebuild them. they can not be >> enabled as they can not build rawhide packages. > >Ok if I change the test to x86-10 as it is EL6 > > >> Dennis >> > > >-- >Stephen J Smoogen. >“The core skill of innovators is error recovery, not failure avoidance.” >Randy Nelson, President of Pixar University. >"We have a strategic plan. It's called doing things."" >— Herb Kelleher, founder Southwest Airlines >_______________________________________________ >infrastructure mailing list >infrastructure(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/infrastructure -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

1 0

Fwd: PROBLEM: koji01.phx2.fedoraproject.org/koji is CRITICAL
by Stephen John Smoogen 24 Jul '10

24 Jul '10

This looks to be some sort of change in koji or the builders is causing this page. The check is to see if x86-01 appears on the website http://koji.fedoraproject.org/koji/hosts however none of the builders x86-01 -> x86-08 show up currently. The systems seem to be active and running but not listed in koji at the moment. ---------- Forwarded message ---------- From: Nagios Monitoring User <nagios(a)fedoraproject.org> Date: Sat, Jul 24, 2010 at 06:18 Subject: PROBLEM: koji01.phx2.fedoraproject.org/koji is CRITICAL Service: koji Host: koji01 Info: HTTP CRITICAL: HTTP/1.1 200 OK - string not found - 14549 bytes in 0.361 second response time Source: noc01 Date: Sat Jul 24 12:18:11 UTC 2010 -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines

2 2

Fwd: RECOVERY: log01.phx2.fedoraproject.org/Disk Space / is OK
by Stephen John Smoogen 24 Jul '10

24 Jul '10

Ok most of the data was taken up by collectd report on spins. It would seem collects was seeing every time something /var/tmp/imagecreate was built and so was logging it which was a lot of files because the names are unique. ---------- Forwarded message ---------- From: Nagios Monitoring User <nagios(a)fedoraproject.org> Date: Sat, Jul 24, 2010 at 08:10 Subject: RECOVERY: log01.phx2.fedoraproject.org/Disk Space / is OK To: smooge+mobile(a)gmail.com Service: Disk Space / Host: log01 Info: DISK OK - free space: / 3277 MB (16% inode=98%): Source: noc01 Date: Sat Jul 24 14:10:41 UTC 2010 -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines

1 0

Outage: Updates - 2010-07-28 16:00->22:00 UTC
by Stephen John Smoogen 24 Jul '10

24 Jul '10

There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 6 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-28 16:00 UTC' Reason for outage: Updates to xen and other critical packages require rebooting servers to take effect. Affected Services: BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ CVS / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2280 -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines

1 1

Upcoming rebuilds: Rebuilding publictestXX and .stg. servers
by Stephen John Smoogen 24 Jul '10

24 Jul '10

Ok its time to start rebuilding the various publictest and .stg. environment to make sure that the systems are 'sound'. I would like to get this started next week with the publictest systems and then the week after with the .stg. systems. The systems that have been in use lately seem to be: publictest2, publictest3, publictest6 and publictest8 I would like to rebuild the following servers first: publictest1 (move people from pt2 here) publictest4 (move people from pt3 here) publictest5 (move people from pt6 here) publictest7 (move people from pt8 here) and have people move to the rebuilt servers. After that I will look at rebuilding or decommissioning the other servers so that we would have 1-8 running either EL-5 or EL-6 beta. Others could be brought up as needed, but would remain generally off for security reasons. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines

1 0

Dedicated hosting
by Vijay Gharge 23 Jul '10

23 Jul '10

Hello Matt, I work here for Vodafone and I am really not sure if they will sponsor any open source activity. I am interested in individual contribution without any expectation from my current employer... But yes...one thing is sure..I can use existing infrastructure for possible feature testing etc. Hope this is ok.. :-) Regards,

2 1

Re: Search Engine on start.fedoraproject.org (fwd)
by Mike McGrath 23 Jul '10

23 Jul '10

FYI, this topic came up recently. I sent it to FAB because it was initially impactful to start.fp.o as a whole (and policies) but we're also starting to talk about infrastructure policies and I wanted to make sure everyone here was in the loop. Start of thread: http://lists.fedoraproject.org/pipermail/advisory-board/2010-July/008750.ht… Policy in question: http://infrastructure.fedoraproject.org/csi/free-software-policy/en-US/html… Specifically "Proprietary Dependence" -Mike ---------- Forwarded message ---------- Date: Thu, 22 Jul 2010 18:41:29 From: Mike McGrath <mmcgrath(a)redhat.com> To: advisory-board(a)lists.fedoraproject.org Subject: Re: Search Engine on start.fedoraproject.org On Thu, 22 Jul 2010, Jeff Spaleta wrote: > On Wed, Jul 21, 2010 at 11:33 AM, Mike McGrath <mmcgrath(a)redhat.com> wrote: > > Thoughts, comments? > > > > -Mike "Sorry but the free road is a hard one sometimes" McGrath > > > Mike and I had a nice little discussion on irc about all this and I > want to sum up my thoughts for everybody about what our policy should > really be in terms of web services. > > First and foremost i think we all need to come into door with an > understanding that all external webservices break traditional > assumptions about how traditional open source licensing(prior to > AGPL-like constructions) provide freedoms to users. Such licensing has > primarily relied on the act of distribution as a key provision to > protecting particular freedoms that we want to retain as users and > developers. Web services break the assumptions that usage by a new > entity requires distribution to that entity. So a lot of our hard > fought consensus understanding on how all this open licensing stuff > works gets thrown under the bus with that underlying assumption. > > A web service could be completely built with openly licensed code > under traditional open licensing (BSD) and we'd never be required to > be given access to that codebase. And even for services that offer > access to a codebase (AGPL), we have no practical ability to verify > that the externally running service does indeed match the codebase we > have access to making it difficult to ensure compliance to the > licensing. > > So with that in mind. I'm going to ask everyone to throw away the > language in the policy that Mike pointed to and ask people to answer a > more fundamental question. What freedoms do we need to > protect/maintain when we choose to rely on _any_ externally built and > maintained web service. > > I'll go ahead and give you how I've answered that question in my > conversation with Mike, but I'm more than happy to have others > disagree with me and express an alternative opinion. > > What I think we need to protect is API compliance and to ensure that > we can reimplement a service on our own as a replacement if the > external service goes up in smoke for some reason. Which means we need > services with documented stable APIs and we need to identify an > existing open codebase that we can rebuild into a replacement service > that conforms to the APIs we make use of in any 3rd party service > provider we choose to rely on.. but not necessarily the same codebase > that the 3rd party service provider is running. > > Anything more restrictive than that as a policy and I think we pretty > much prevent ourselves from depending on any external service without > bending the policy way way out of shape to meet the practical > realities of relying on any external service provider...cough Red Hat > bugzilla...cough. > > And I don't mean that we ensure that we can build an equivalent > service in-house either. There's a lot about the day-to-day utility of > a service, even with open codebase, that can't be replicated without a > signficant infrastructure investment that we simply aren't going to be > able to make all the time. We _could_ build our on in-house search > engine, but we aren't going to be investing in the infrastructure to > index the web very effectively so our in-house service would have > drastically reduced utility. But we could build it if we felt we had > to. > > It really comes down to API restraint on our part. We restrict > ourselves to the use of services with published APIs, and we ensure > there is an open codebase out in the wild that conforms to those APIs > and we squirrel that codebase away as a hedge against the external > service provider going dark or closing down its public APIs. > I liked one of the examples we talked about right at the end of that conversation with rsync.net. We considered rsync.net as a backup solution. This was something that was pretty clearly easy for us to duplicate if we wanted to but for cost reasons or whatever we could have just paid rsync.net for the storage. Now, the api for rsync is pretty well documented, there are several implementations. But we had no promises that rsync.net was even running a FOSS version of rsync, nor what OS they may have been running, etc. By that definition our current policy would have disallowed us from using rsync.net but I don't think it should have. So the policy will have to be altered a bit in that respect. At the same time, Google's search API is pretty well open. It just uses an http GET url and you get your results. However, it does seem google's actual search is closed. So we certainly couldn't provide our own google if we wanted (ignoring content licensing and size for now). So now the trick is to try to find wording that describes what Jef said above. We don't want to be locked into a vendor and we do want to be able to duplicate an external service on our own if the service goes away. I'd also like wording that states that "duplicating it ourselves" does not mean "writing our own rsync". I think Jeff's comment about API restraint is going to go in the policy as a "must" requirement. But I think there's some should's there about actual software availability. If we actually do start relying on some external service and it goes away and our own recourse is to build our own from scratch, that's a recipe for disaster. But if our recourse is to install some software and can duplicate (or near duplicate) the functionality I think that's more feasible and realistic. I'll continue to mull over this a bit. We want a simple policy that's easy to understand but still protects our values. Please do comment if you have thoughts on this. -Mike

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure July 2010