<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Can you shed some light on the problems with using celerybeat with Pulp 3?</div><div><br></div><div>Michael</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 3:55 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This came out of IRC and discussion on a Pulp3 MVP call...<br><br></div><div>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 '<span class="m_4226353163870977039gmail-pl-s">download_deferred_content<span class="m_4226353163870977039gmail-pl-pds">' is required for lazy downloading correctness.<br><br></span></span></div><div><span class="m_4226353163870977039gmail-pl-s"><span class="m_4226353163870977039gmail-pl-pds">Can others confirm that for Pulp3 we will require the download_deferred_content Celery task?<br><br></span></span></div><div><span class="m_4226353163870977039gmail-pl-s"><span class="m_4226353163870977039gmail-pl-pds">Once we confirm ^, I want to discuss why we should not implement it in Pulp3 how we did in Pulp2.<br><br>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 [1][2].<br><br></span></span>[0]: <a href="https://github.com/pulp/pulp/blob/fba39f1a82bbf8666df64999e89bc21d6d5ec897/server/pulp/server/async/celery_instance.py#L24-L40" target="_blank">https://github.com/pulp/pulp/<wbr>blob/<wbr>fba39f1a82bbf8666df64999e89bc2<wbr>1d6d5ec897/server/pulp/server/<wbr>async/celery_instance.py#L24-<wbr>L40</a><br>[1]: <a href="http://pulpproject.org/2016/12/07/deprecating-nodes/" target="_blank">http://pulpproject.org/2016/<wbr>12/07/deprecating-nodes/</a><br>[2]: <a href="http://pulpproject.org/2016/10/31/pulp-3.0-mvp/" target="_blank">http://pulpproject.org/2016/<wbr>10/31/pulp-3.0-mvp/</a><span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>-Brian<br></div></font></span></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>