[Pulp-dev] Lazy for Pulp3
bbouters at redhat.com
Wed Jun 6 17:17:55 UTC 2018
On Mon, Jun 4, 2018 at 12:45 PM, Bryan Kearney <bkearney at 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) 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?
> -- bk
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev