warthog9 asked me to write him this mail regarding setup of permanent
mirror of static-repos.
Why a static-repos mirror?
It is helpful during the rawhide development cycle for hard-core rawhide
developers/testers to update their rawhide boxes directly from the
buildroot repos used by koji.
For example, during the freeze periods of F8 development I updated my
laptop from static-repos several times per day. Sometimes a new build
broke something in a very obvious fashion. Due to this advance warning,
I prevented a few utterly broken packages (like kernel) from hitting the
rawhide nightly tree.
Traditional rawhide compose + syncing to mirrors means the
build/install/test/report turnaround cycle for rawhide is 1-2 days
minimum. If some testers update from static-repos, the turnaround time
could be as short as 30 minutes. If this quick turnaround allows more
nightly rawhide trees to be installable, this tremendously aids our
overall testing ability and ultimate release quality.
Of course, it would be a huge mistake to point people directly to
koji/static-repos, because we can't afford to bog it down.
Thus a caching mirror of static-repos would allow us to more widely
advertise the option of updating rawhide directly from static-repos.
What do we need?
- 1 dedicated IP address.
- squid configured as reverse proxy server.
- ~15GB disk for squid cache.
- Metadata refresh monitoring daemon, can run as non-root anywhere on
the Internet. We could run this on a fedoraproject.org server. squid
needs to be configured to allow the IP address where the refresh daemon
is running to do the PURGE command.
- Bandwidth... although not very much, since this is a non-default repo,
few people will be using it.
What will Warren Provide?
- Sample squid configuration file.
- Time and attention to set this up.
- Continued maintenance of the refresh monitoring daemon. Since this
runs at fedoraproject.org, this requires no attention from warthog9.
How does this sound warthog9?
Fedora-infrastructure-list mailing list