Thank you all for your answers, that makes sense. I guess what I failed to ask was about repository naming schemes and repository discovery, so my example wasn't the best.
Say I am shipping version 2.0 (of some imaginary software) to our customers. Bug fixes will continue to be pushed to the 2.0 repository. Later, I am shipping version 2.1, 2.2 etc. Presumably these go into their own repo. I would like to have a programmatic way of comparing repositories, so that I can write a wrapper around yum that notices the presence of a "new" repository and offers the possibility of an upgrade to the user of said wrapper. In other words, I don't want to automatically update my customers to 2.1 if they're not ready to consume it, but I do want them to periodically run yum update and fetch bug fixes (or security fixes from upstream repos). So: can pulp repositories be grouped in a logical way? I noticed pulp-admin repo group exists, is that the way to do it? The docs at https://pulp-user-guide.readthedocs.org/en/pulp-2.2/admin-client/repositories.html seem to imply there is further development needed to make this useful. Second: is there any meta-information about repositories in yum, that would group a bunch of repos together? I would prefer not to parse HTML when trying to determine new versions of the repositories. Thank you again! Mihai On Fri, Sep 11, 2015 at 2:10 PM, Baird, Josh <[email protected]> wrote: > Hi, > > > > We create dated snapshots of RHEL repositories (using pulp rpm repo > copy). For instance, for 7Server, we may have the following repo path: > > > > /pulp/repos/rhel/7Server/x86_64/snapshot/20150727/{os,extras,rhscl,etc} > > > > Our configuration management system allows us to define a snapshot date > for each tier of host in our environment (DEV, QA, PROD, etc). When we cut > a new snapshot (usually quarterly), we 'pulp rpm repo copy rpm' from the > "bleeding edge" RHEL repository (which is synced nightly) to the snapshot > repository. All DEV hosts get pointed at the new repository for testing, > and eventually we point all PROD hosts to the new snapshot date once the > updates have been tested. > > > > For each dated snapshot, we also have an "emergency" repository: > > > > /pulp/repos/7Server/x86_64/snapshot/20150727/emergency > > > > This repository is used to promote critical/emergency packages out of > band. In this case, we again use 'pulp rpm repo copy' to promote > individual packages from the 'bleeding edge' repository into the dated > 'emergency' snapshot repository. This makes critical packages immediately > available to all hosts currently assigned to that snapshot without having > to cut an entirely new snapshot of all packages. > > > > Our hosts are provisioned using the snapshot repositories as well, which > ensures that all systems have a consistent set of packages. Hope this > helps. > > > > Thanks, > > > > Josh > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Mihai Ibanescu > *Sent:* Friday, September 11, 2015 12:43 PM > *To:* pulp-list > *Subject:* [Pulp-list] Repository layout > > > > Hi, > > > > Is there a best practice document for how to keep a set of systems on a > specific version of a distro? > > > > Say, all the testing was done against Centos 6.5, but 6.6 and 6.7 are out. > I want my production systems to work with 6.5 but my QA is on 6.6 and I am > developing against 6.7. > > > > I am trying to figure out how to lay out the repositories in pulp. I > suspect the answer is 3 different repos, and creatively/carefully copying > errata (with their packages) from 6.7 into the 6.5 repo. > > > > Please don't ask why I wouldn't want to be on latest all the time. It is a > somewhat contrived example of a real-life situation. > > > > Thank you! > > Mihai >
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
