[Pulp-list] repository environments and promoting

Ina Panova ipanova at redhat.com
Tue Sep 6 09:52:36 UTC 2016

There is one optional config parameter for importer 'retain_old_count'. It is
responsible for of how many old rpm versions to retain, unfortunately that
option works just with sync operation. For the same reason 'remove-missing' is
not applicable on copy operation and that's why RPMs that don't exist on source
won't be deleted from dest.

Maybe it would be a good candidate for filling a RFE.

As a workaround you could provide in the destination repository feed of source
repo and retain_old_count option will be applied during sync.
Or simply provide in the feed of destination repo local path --feed file:// and
sync the content into the repo.


Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

----- Original Message -----
From: "Brian Bouterse" <bbouters at redhat.com>
To: pulp-list at redhat.com
Sent: Monday, September 5, 2016 3:40:16 PM
Subject: Re: [Pulp-list] repository environments and promoting

FYI, you can copy a specific RPM if you apply a filter. The filtering is 
2.y is cumbersome so I don't have a ready example, but it can be done. 
You can do it with additional arguments to `pulp-admin rpm repo copy 
rpm`. Those filters correspond with this API endpoint [0]. There are 
also a lot of copy examples for rpm plugin types [1].

I also believe that copying only the latest is an option, but I couldn't 
find that in the docs. Maybe another user or dev can point us to them.

Copy is additive so I expect that RPMs that don't exist on the source 
won't be deleted from dest. A feature Pulp doesn't support is the 
removal of content from the destination with a copy operation. For the 
use case where you want one repo to become exactly like the other you 
could remove all units from the destination and then copy all.

[1]: http://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html


On 09/05/2016 05:11 AM, Vladimir Vasilev wrote:
> Hi,
> I was thinking and testing the same approach, with "copy rpm".
> A few disadvantages:
> you cannot copy specific RPM
> you cannot copy only latest versions.
> RPMs that don't exist on source won't be deleted from dest
> Or maybe there's some filters which can do that above.
> What I like more is having the prod repositories configured to sync from
> stage with:
> --feed=XXX |--remove-missing=true --download-policy=on_demand
> ||--relative-url=XXX
> Then you upload/publish to stage and later just run sync for prod.
> No one must push directly to prod. I just wonder how can I enforce this
> on the server side.
> |
> On 09/05/16 08:28, Vaclav Adamec wrote:
>> Hi,
>>  I'm using Ansible playbooks for deployment and Puppet+Hiera to setup
>> repozitories on servers (right now about 30 repozitories at all, about
>> 5 per server). All servers have disabled live repozitories (for
>> security patches) and enabled assigned stage (dev has live,
>> integration unstable, production stable). Than it's just a pipeline of
>> commands on Ansible playbook like this:
>> # Live repo runs two times per day
>> rpm repo sync run --repo-id=centos_live
>> rpm repo publish run --repo-id=centos6_live
>> #Every week
>> rpm repo copy rpm --from-repo-id=centos6_live centos6_unstable
>> rpm repo publish run ...
>> #Every month
>> rpm repo copy rpm --from-repo-id= centos6_unstable centos6_stable
>> rpm repo publish run ...
>> After publishing Ansible playbook will run update on all servers in
>> given stage.
>> Is that something what do you want to achieve ? As a simple GUI I'm
>> using Jenkins (as a smarter crontab) and ocsreports to get back
>> installed packages and system overview. Pulp server is behind caching
>> Nginx proxies (just RPMs, not metadata). I don't using any kind of
>> registration to Pulp as for dynamic/cloud environment it's more or
>> less stupid idea.
>> Vasek
>> On Sat, Sep 3, 2016 at 12:56 PM, Vladimir Vasilev <vvasilev at redhat.com
>> <mailto:vvasilev at redhat.com>> wrote:
>>     Hi,
>>     I checked the latest pulp docs and can't find this..
>>     Is there a way to have environments (dev->stage->prod or any) and kind
>>     of promote RPMs to the upper?
>>     I see some "content environment" in [1] but the idea is different.
>>     There's copy from one repo to another and again to method to copy
>>     specific RPMs or latest versions.
>>     Looks like juicer [2] is trying to solve this. We use it for one
>>     client
>>     and it works. Downside is that I'm stuck with 3rd party tool.
>>     [1]
>>     https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html
>>     <https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html>
>>     [2] https://github.com/juicer/juicer
>>     <https://github.com/juicer/juicer>
>>     _______________________________________________
>>     Pulp-list mailing list
>>     Pulp-list at redhat.com <mailto:Pulp-list at redhat.com>
>>     https://www.redhat.com/mailman/listinfo/pulp-list
>>     <https://www.redhat.com/mailman/listinfo/pulp-list>
>> --
>> -- May the fox be with you ...
>>    /\
>>   (~(
>>    ) )         /\_/\
>>   (_=---_(@ @)
>>     (          \   /
>>     /|/----\|\  V
>>     " "     " "
> --
> Vladimir Vasilev
> Senior Systems Administrator
> PnT DevOps - System Operations
> Red Hat Czech s.r.o., Purkynova 99, 612 00 Brno, Czech Republic
> Work: +420 532-294-569
> Cell: +420 737-080-404
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list

Pulp-list mailing list
Pulp-list at redhat.com

More information about the Pulp-list mailing list