[Pulp-list] Repository layout

[Mihai Ibanescu]

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 <jbaird at follett.com> 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:* pulp-list-bounces at redhat.com [mailto:pulp-list-bounces at redhat.com]
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20150911/21d42968/attachment.htm>