[Pulp-list] Simple use case of mirroring external repos in pulp3

[Matthias Dellweg]

Hi Jim,
thanks for reaching out. I think the use case you are describing here is
best described in
https://pulp-rpm.readthedocs.io/en/latest/workflows/create_sync_publish.html#sync-publish-workflow
.
And yes it is necessary to sync, publish and distribute that repository to
have a mirror. Also this mirror will AFAIK republish the synched repository
in its own layout. (Anyone, please help me out if i'm wrong!)
We have recently discussed the possibility to republish synched repository
versions in a verbatim manner (including all files and original metadata in
their original relative location). Let us know if that is an important use
case for you.
As of the CLI for pulp3, it is in a very ealy poc/planning phase. But
personally, i would love to hear if you made any experience with using the
ansible modules in https://galaxy.ansible.com/pulp/squeezer (also
incomplete, but there are some for use with RPM facilities).
  Matthias

On Mon, Sep 21, 2020 at 10:27 PM Jim Davis <JDavis at douglas.co.us> wrote:

> For some time now I have built up several pulp2 mirrors of various
> upstream rpm repos to make local updates run faster and to segregate
> environments. I do not require client registration so it is a dirt simple
> setup for basic OS patching. It is trivial to rebuild my rpm repositories
> if needed and to sync them as needed via scripts using pulp_admin.
>
>
>
> I’m trying to figure out how to do this with pulp3 – and I’m still a bit
> puzzled. The pulp3 ansible deploy method is really quite slick. One issue
> down. Simply mirroring outside repos is quite common with pulp2 usage and
> documented everywhere in the webnets but not so much for pulp3. I realize
> the CLI went away but surely there must be some pulp2 to pulp3 task
> equivalence somewhere or maybe someone has real world examples written up
> already and hasn’t yet published them. Searching/reading/searching gives me
> lots of information on complex issues around document versioning, history,
> plugins, API usage, pulp3 architecture, etc. For me this makes a simple
> migration to pulp3 more difficult for probably the easiest use case out
> there. Am I too early to the game to consider a move or is it all in front
> of me but in a million pieces!
>
>
>
> Thanks
>
>
>
> Jim
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20200922/fdddfc86/attachment.htm>