As I'm thinking about it some more, what I think I really want is a way to export some sort of "manifest" that can tell the downstream pulp server to build a repo using packages A2.0, B1.0 and D1.0. Pulp would then know that it already has B1.0 in its content store and that A2.0 and D1.0 are in the import location. Or, if I could just import A2.0 and D1.0 into the pulp content store and then create a new repo using a package manifest.
In that scenario, A1.0 and C1.0 would be orphaned and removed when I cleaned all the orphans. On Thu, May 14, 2015 at 7:21 PM, Mike Griffin <[email protected]> wrote: > Thanks for the response. I'm using pulp2.6.1 and my plan is to have a pulp > server on both sides. > > Maybe I can illustrate my requirements a little easier. For example: > During my first month of April, package A-1.0, B-1.0, and C-1.0 are > downloaded via the nightly sync. When I create my release, all 3 packages > appear in my export and I move them downstream. > > The next month when I create my release-set, package A is updated to > version 2.0, B is static, C is removed upstream and D1.0 is released. Since > I have my nightly sync set to "remove-missing true" and "retain-old-count > 0", A1.0 and C1.0 should be removed from the sync repo and therefore > removed from the release-set. I want to move A2.0 and D1.0 downstream, copy > B1.0 that already exists downstream and re-create the release directory > there (A2.0, B1.0, D1.0). > > > On Thu, May 14, 2015 at 7:01 PM, Barnaby Court <[email protected]> wrote: > >> Hi, >> >> Having an internet connected pulp server could definitely help with >> creating releases like this. A couple of questions: >> >> Could you help with explaining about more in terms of what you are >> looking for regarding pruning? Export is challenging for this since what is >> exported is a yum repository, it does not include information about >> packages that have been removed. >> Are you considering running a Pulp server on your disconnected network to >> make the data available there? >> Exporting a repository by default creates the mirror of what you would >> get by accessing it from the pulp server directly. The start-date and >> end-date parameters are specifically designed for incremental exports. Can >> you give a specific example of what is missing from the generated iso when >> you use those parameters? >> One last question, what version of Pulp are you using? Thanks! >> >> -Barnaby >> >> ------------------------------ >> *From: *"Mike Griffin" <[email protected]> >> *To: *[email protected] >> *Sent: *Thursday, May 14, 2015 6:23:45 PM >> *Subject: *[Pulp-list] Using pulp to create monthly releases >> >> >> I'm looking for a way to efficiently use pulp to create monthly releases >> for repos on my disconnected network. >> >> My initial thought is to have my internet-connected pulp server nightly >> sync the repos into some -stage repo, then once a month "cut" the release, >> by copying the -stage repo into a -release repo. What I'm stuck on is how I >> could determine what changes were made from month to month and move just >> the changes, along with the updates to the repodata (comps.xml, etc). I >> want to prune the old packages out as well as add the new ones. I know that >> the export has --start-date and --end-date parameters, but that does not >> export the updated repodata, nor does it give me the removed packages. >> Also, the export doesn't allow me to re-create the release repo in its >> entirety on the other side. >> >> Has anyone else thought about how to create monthly releases? >> >> Thanks >> -- >> Regards, >> Mike Griffin >> >> Ever grateful, ever true >> >> _______________________________________________ >> Pulp-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-list >> >> > > > -- > Regards, > Mike Griffin > > Ever grateful, ever true > -- Regards, Mike Griffin Ever grateful, ever true
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
