On 06/06/2018 01:17 PM, Brian Bouterse wrote: > > On Mon, Jun 4, 2018 at 12:45 PM, Bryan Kearney <bkear...@redhat.com > <mailto:bkear...@redhat.com>> wrote: > > On 05/31/2018 06:36 PM, Jeff Ortel wrote: > > > > > > On 05/31/2018 04:39 PM, Brian Bouterse wrote: > >> I updated the epic (https://pulp.plan.io/issues/3693 > <https://pulp.plan.io/issues/3693>) > to use this new > >> language. > >> > >> policy=immediate -> downloads now while the task runs (no lazy). Also > >> the default if unspecified. > >> policy=cache-and-save -> All the steps in the diagram. Content that > >> is downloaded is saved so that it's only ever downloaded once. > >> policy=cache -> All the steps in the diagram except step 14. If > >> squid pushes the bits out of the cache, it will be re-downloaded again > >> to serve to other clients requesting the same bits. > > If this became a requirement, another implementation of what tom is > asking is bulk job to clean out old cached content. I assume > cache-and-save with a 2 week purge would be the same end result and not > require alot of net new coding. > > > I believe these features would layer on top of the current plan > reasonably well. I want to describe the user experience on this concept. > > Purging content would probably be a process where the associated > ContentUnit is updated to not be associated with the saved Artifact; > this would cause the Artifact to become an Orphaned Artifact. After > that, the user would need to run orphan cleanup to actually delete that > Artifact from the db and the storage system. This 2-step thing is due to > a correctness requirement that Orphaned Artifact deletion has to be run > without any other Pulp jobs executing. The orphan cleanup already does > this correctly so this purging would probably occur like this for now. > > Would ^ type of execution work for this type of purging use case?
I think what I want is "go back to ondemand". So, what state is the system in when only the metadata is downloaded, and not the artifact? -- bk
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
