[Pulp-dev] "Internal" periodic tasks in Pulp3?
mhrivnak at redhat.com
Wed Mar 29 14:13:18 UTC 2017
I think we could probably engineer our way around the requirement to run
that periodic task if we had to. But we should weigh that against what it
would take to continue using celerybeat.
Generally, I think we'll continue to find value in having something that
can run periodic tasks for internal purposes. Trimming history is one good
example, not just for the cases Pulp 2 currently does, but also for things
like repo versions. Celerybeat doesn't have to be the thing that initiates
periodic tasks, but it's a reasonable starting place since we already use
it that way.
Can you shed some light on the problems with using celerybeat with Pulp 3?
On Tue, Mar 28, 2017 at 3:55 PM, Brian Bouterse <bbouters at redhat.com> wrote:
> This came out of IRC and discussion on a Pulp3 MVP call...
> In Pulp2 we had three "internal" periodic tasks  that would do things
> like database maintenance. The "nice to have" maintained periodic tasks can
> be left out of the Pulp3 MVP, but @mhrivnak identified that '
> download_deferred_content' is required for lazy downloading correctness.
> Can others confirm that for Pulp3 we will require the
> download_deferred_content Celery task?
> Once we confirm ^, I want to discuss why we should not implement it in
> Pulp3 how we did in Pulp2.
> Note, internal periodic calls is not the same as "user scheduled calls".
> Pulp3 will is not supporting user scheduled calls for reasons identified in
> these blog posts .
> : https://github.com/pulp/pulp/blob/fba39f1a82bbf8666df64999e89bc2
> : http://pulpproject.org/2016/12/07/deprecating-nodes/
> : http://pulpproject.org/2016/10/31/pulp-3.0-mvp/
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev