<div dir="ltr">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.<br><br>[0] <a href="https://pulp.plan.io/issues/2615">https://pulp.plan.io/issues/2615</a><br>[1] <a href="https://github.com/pulp/pulp/pull/2968/files">https://github.com/pulp/pulp/pull/2968/files</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 10:44 AM, 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>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 Pulp3 we don't have that requirement anymore so that is what is changing in terms of the benefit of celerybeat.<br><br>Now here are the problems with Celerybeat and Pulp:<br><br>* It's fragile. Pulp's custom scheduler relies on internal behaviors of Celerybeat that are not part of an API. We have spent a lot more time fixing than we would with a much smaller code base of our own code.<br></div><div><br>* Celerybeat does not support high availability (HA) or failover but Pulp's use of Celerybeat is specifically HA. Their feature is not a good fit for our needs. This requires our Scheduler to take special care with how we hack the internals of Celery. We would do better to get the periodic dispatch feature without Celery.<br><br>* Not much benefit from Celerybeat. For all the time and care ^ we need to put into working with it, we aren't getting much benefit in Pulp3 due to "dynamic user facing schedules" not being part of Pulp3. With that requirements change the value proposition from Celerybeat is very limited which makes the risk not worth it.<br><br>* The alternatives are very simple and easy. A single thread in the Celerybeat process that does not call into Celery code could do all of this in ~20 lines of code.<br><br></div><div>As an aside, if we did engineer a way to not have the periodic tasks as part of the Pulp3 MVP, we would be able to eliminate Celerybeat from the Pulp architecture entirely.<br></div><div><br>[0]: <a href="https://github.com/EvanK/rcron" target="_blank">https://github.com/EvanK/rcron</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><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 10:13 AM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@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">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"><div><div class="m_2422231252978909271h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_2422231252978909271h5"><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_2422231252978909271m_-3665334814067973213m_4226353163870977039gmail-pl-s">download_deferred_content<span class="m_2422231252978909271m_-3665334814067973213m_4226353163870977039gmail-pl-pds">' is required for lazy downloading correctness.<br><br></span></span></div><div><span class="m_2422231252978909271m_-3665334814067973213m_4226353163870977039gmail-pl-s"><span class="m_2422231252978909271m_-3665334814067973213m_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_2422231252978909271m_-3665334814067973213m_4226353163870977039gmail-pl-s"><span class="m_2422231252978909271m_-3665334814067973213m_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/b<wbr>lob/fba39f1a82bbf8666df64999e8<wbr>9bc21d6d5ec897/server/pulp/ser<wbr>ver/async/celery_instance.py#<wbr>L24-L40</a><br>[1]: <a href="http://pulpproject.org/2016/12/07/deprecating-nodes/" target="_blank">http://pulpproject.org/2016/12<wbr>/07/deprecating-nodes/</a><br>[2]: <a href="http://pulpproject.org/2016/10/31/pulp-3.0-mvp/" target="_blank">http://pulpproject.org/2016/10<wbr>/31/pulp-3.0-mvp/</a><span class="m_2422231252978909271m_-3665334814067973213HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_2422231252978909271m_-3665334814067973213HOEnZb"><font color="#888888"><div>-Brian<br></div></font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></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>