Repo Maintenance Options
Current maintenance options are related to propagation chain maintenance.
Let us assume, you have three environments: dev, qa, prod and three repositories dev-repo, qa-repo, and prod-repo. We would suggest to configure a propagation chain as follows: All servers in prod are connected to prod-repo, all servers in qa are connected to qa-repo and prod-repo, all servers in dev are connected to dev-repo, qa-repo and prod-repo. In this case prod-repo will be the repo with the most RPMs inside. Dev-repo and qa-repo will only have release candidates of RPMs that have a pending change. All other RPMs will be fetched by all servers from pro-repo.
We call this setup of repose, dev-repo, qa-repo and prod-repo a propagation chain. If you want to test a new version of a new RPM, you first put it into the dev-repo, update some test machines and validate the RPM. If this is successfull, you propagate (move) the RPM from dev-repo to qa-repo. Now the RPM is available to all dev and all qa servers. If you are happy with this version in qa too, you propagate the RPM to pro-repo, and than it is available in all stages.
As the Yum Repo Server (by design) has no knowledge about which repos form a propagation chain, you need to supply two repo names in maintenance forms.
A RPM in a lower level repo (for example dev-repo) is considered obsolete, if in a higher level repo (for example pro-repo) is a RPM available with the same name and architecture and a higher version. In this case the obsolete RPM will never be used for an update in any stage. And we consider version pinning a bad idea. Thus we would delete the obsolete RPM from the lower level repo.
A RPM in a lower level repo (for example dev-repo) is considered propagatable, if in a higher level repo (for example pro-repo) there is either no RPM with the same name and architecture, or there are only RPM available with the same name and architecture and lower versions. If successfully tested, the propagatable RPM could be propagated to the higher level repo.
Use the max RPMs to keep setting in repo info
