Greetings.
As many of you know, we have our own infrastructure repository. This is used for corner case packages that we need, but cannot be in the main EPEL or RHEL repos we use.
https://fedoraproject.org/wiki/Infrastructure_Yum_Repo_SOP
Some reasons might be:
* Theme or branding files that can only be used by us.
* Upgrades to base RHEL packages that are needed for producing fedora.
* Updates that we need sooner than the EPEL 2 week cycle of testing.
* (might be others here?)
I've added a section to the above SOP:
https://fedoraproject.org/wiki/Infrastructure_Yum_Repo_SOP#Add_information_a...
If we could start noting why we are adding something and who's responsible for it, that would be great. :) Also, if someone would like to look at whats being used from that repo currently we could fill in the info on any of them that are currently active that would be great.
In looking at whats in there now, there's a ton of old packages, many of which I suspect we are no longer using anywhere at all. Do we want to clean this out and move old packages to an archive repo or delete them? I guess they are only taking up disk space really...
Thoughts/comments welcome.
kevin
On Tue, 2011-04-12 at 13:47 -0600, Kevin Fenzi wrote:
Greetings.
As many of you know, we have our own infrastructure repository. This is used for corner case packages that we need, but cannot be in the main EPEL or RHEL repos we use.
https://fedoraproject.org/wiki/Infrastructure_Yum_Repo_SOP
Some reasons might be:
Theme or branding files that can only be used by us.
Upgrades to base RHEL packages that are needed for producing fedora.
Updates that we need sooner than the EPEL 2 week cycle of testing.
(might be others here?)
I've added a section to the above SOP:
https://fedoraproject.org/wiki/Infrastructure_Yum_Repo_SOP#Add_information_a...
If we could start noting why we are adding something and who's responsible for it, that would be great. :) Also, if someone would like to look at whats being used from that repo currently we could fill in the info on any of them that are currently active that would be great.
In looking at whats in there now, there's a ton of old packages, many of which I suspect we are no longer using anywhere at all. Do we want to clean this out and move old packages to an archive repo or delete them? I guess they are only taking up disk space really...
Thoughts/comments welcome.
I think I can generate a list of machines who have a package installed from that repo.
we can narrow that way. I suspect we have a lot of crap in there :)
-sv
On Tue, 12 Apr 2011 16:52:32 -0400 seth vidal skvidal@fedoraproject.org wrote:
I think I can generate a list of machines who have a package installed from that repo.
That could be good to have.
we can narrow that way. I suspect we have a lot of crap in there :)
yep. There's some very old packages in there...
kevin
On Wed, 2011-04-13 at 10:25 -0600, Kevin Fenzi wrote:
On Tue, 12 Apr 2011 16:52:32 -0400 seth vidal skvidal@fedoraproject.org wrote:
I think I can generate a list of machines who have a package installed from that repo.
That could be good to have.
we can narrow that way. I suspect we have a lot of crap in there :)
yep. There's some very old packages in there...
Provided the list today it's in /tmp on puppet1.
-sv
On Tue, Apr 12, 2011 at 01:47:52PM -0600, Kevin Fenzi wrote:
In looking at whats in there now, there's a ton of old packages, many of which I suspect we are no longer using anywhere at all. Do we want to clean this out and move old packages to an archive repo or delete them? I guess they are only taking up disk space really...
For things that we're no longer using because there's a newer version in EPEL/RHEL/etc, we probably want to delete them. Sometimes we have newer versions there because we need to deploy some changes immediately and they need a newer package of a dependency (or we pull a new build from koji directly instead of waiting for the build to enter EPEL-testing). Once those sorts of packages make it into the official repos, we no longer need to keep the old packages in infra.fp.o
-Toshio
On Tue, 12 Apr 2011 20:40:34 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Tue, Apr 12, 2011 at 01:47:52PM -0600, Kevin Fenzi wrote:
In looking at whats in there now, there's a ton of old packages, many of which I suspect we are no longer using anywhere at all. Do we want to clean this out and move old packages to an archive repo or delete them? I guess they are only taking up disk space really...
For things that we're no longer using because there's a newer version in EPEL/RHEL/etc, we probably want to delete them. Sometimes we have newer versions there because we need to deploy some changes immediately and they need a newer package of a dependency (or we pull a new build from koji directly instead of waiting for the build to enter EPEL-testing). Once those sorts of packages make it into the official repos, we no longer need to keep the old packages in infra.fp.o
How about this:
* always keep the src.rpm around for anything in the SRPMS repo. Since this repo isn't used directly much it shouldn't matter that it grows. If we need an old package for some reason we can just rebuild it.
* Once per cycle we clean out the i386/x86_64 packages that are no longer installed on any machine.
(As a side note, I am thinking we should setup a Housekeeping SOP for once per cycle a few weeks after release... we can then do this, prune people who don't need to be in sysadmin groups anymore, prune hosted projects or lists, etc. Of course thats another topic).
kevin
On Wed, Apr 13, 2011 at 10:28:22AM -0600, Kevin Fenzi wrote:
On Tue, 12 Apr 2011 20:40:34 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Tue, Apr 12, 2011 at 01:47:52PM -0600, Kevin Fenzi wrote:
In looking at whats in there now, there's a ton of old packages, many of which I suspect we are no longer using anywhere at all. Do we want to clean this out and move old packages to an archive repo or delete them? I guess they are only taking up disk space really...
For things that we're no longer using because there's a newer version in EPEL/RHEL/etc, we probably want to delete them. Sometimes we have newer versions there because we need to deploy some changes immediately and they need a newer package of a dependency (or we pull a new build from koji directly instead of waiting for the build to enter EPEL-testing). Once those sorts of packages make it into the official repos, we no longer need to keep the old packages in infra.fp.o
How about this:
- always keep the src.rpm around for anything in the SRPMS repo. Since this repo isn't used directly much it shouldn't matter that it grows. If we need an old package for some reason we can just rebuild it.
We can probably age out and discard those SRPMS as well... I do try to clean out old releases for fas and pkgdb, for instance.
I do tend to keep at least one older version around -- I suppose that we could just do that in the SRPM repo and only keep newest in the RPM repo... although the primary reason to keep older packages is to be able to revert within the first week or so of a new release in case something is wrong with an update. Quick reversion means having the last binary packages stick around.
- Once per cycle we clean out the i386/x86_64 packages that are no longer installed on any machine.
+1
(As a side note, I am thinking we should setup a Housekeeping SOP for once per cycle a few weeks after release... we can then do this, prune people who don't need to be in sysadmin groups anymore, prune hosted projects or lists, etc. Of course thats another topic).
Also +1.
-Toshio
On Wed, 13 Apr 2011 12:14:37 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
We can probably age out and discard those SRPMS as well... I do try to clean out old releases for fas and pkgdb, for instance.
I was thinking more for the historical record if we needed it. Ie, someone needs to know what fas version we used at time X and what was in that package. If we have the srpm and timestamp we could examine it. In practice I doubt it would come up much, especially if those packages don't have any local patches, just newer versions...
I do tend to keep at least one older version around -- I suppose that we could just do that in the SRPM repo and only keep newest in the RPM repo... although the primary reason to keep older packages is to be able to revert within the first week or so of a new release in case something is wrong with an update. Quick reversion means having the last binary packages stick around.
Yeah. Keeping one old one around seems reasonable.
- Once per cycle we clean out the i386/x86_64 packages that are no longer installed on any machine.
+1
(As a side note, I am thinking we should setup a Housekeeping SOP for once per cycle a few weeks after release... we can then do this, prune people who don't need to be in sysadmin groups anymore, prune hosted projects or lists, etc. Of course thats another topic).
Also +1.
Draft here: https://fedoraproject.org/wiki/Infrastructure_post_release_housekeeping
will clean up and try and get it to the point of discussing. ;)
kevin
All the copies of mirrormanager can get nuked directly. Dennis beat on me for throwing them in there rather than wait for them to propagate to epel-testing when I wanted them...
-- Matt Domsch Technology Strategist Dell | Office of the CTO
-----Original Message----- From: infrastructure-bounces@lists.fedoraproject.org [mailto:infrastructure-bounces@lists.fedoraproject.org] On Behalf Of Kevin Fenzi Sent: Wednesday, April 13, 2011 2:35 PM To: Fedora Infrastructure Subject: Re: Infrastructure repo
On Wed, 13 Apr 2011 12:14:37 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
We can probably age out and discard those SRPMS as well... I do try to clean out old releases for fas and pkgdb, for instance.
I was thinking more for the historical record if we needed it. Ie, someone needs to know what fas version we used at time X and what was in that package. If we have the srpm and timestamp we could examine it. In practice I doubt it would come up much, especially if those packages don't have any local patches, just newer versions...
I do tend to keep at least one older version around -- I suppose that we could just do that in the SRPM repo and only keep newest in the RPM repo... although the primary reason to keep older packages is to be able to revert within the first week or so of a new release in case something is wrong with an update. Quick reversion means having the last binary packages stick around.
Yeah. Keeping one old one around seems reasonable.
- Once per cycle we clean out the i386/x86_64 packages that are no longer installed on any machine.
+1
(As a side note, I am thinking we should setup a Housekeeping SOP for once per cycle a few weeks after release... we can then do this, prune people who don't need to be in sysadmin groups anymore, prune hosted projects or lists, etc. Of course thats another topic).
Also +1.
Draft here: https://fedoraproject.org/wiki/Infrastructure_post_release_housekeeping
will clean up and try and get it to the point of discussing. ;)
kevin
infrastructure@lists.fedoraproject.org