I concur with everything Brian has said here. Our reliance on hacking the
internals of the Celery scheduler means that we are susceptible to
breakages when they change those internals [0] which we must work around
[1]. It would be best to stick with public, stable interfaces.
[0] https://pulp.pl
We can easily continue to dispatch internal periodic tasks using code we
write and maintain, or we can find a dedicated project for an HA-cron like
rcron[0]. Using Celerybeat made sense in Pulp2 because the requirement of
dynamic, user facing schedules is exactly what celerybeat provides. With
Pulp
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 p
This came out of IRC and discussion on a Pulp3 MVP call...
In Pulp2 we had three "internal" periodic tasks [0] 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' i
