<div dir="ltr">Not being familiar with RQ, I have questions (but no opinion).<div><br></div><div>Will we also be replacing RabbitMQ with Redis?</div><div>Does anyone on the team have experience with RQ? In production?</div><div>How well does RQ scale?</div><div>Is RQ's use of `pickle` a problem? <a href="https://pulp.plan.io/issues/23">https://pulp.plan.io/issues/23</a></div><div>RQ doesn't work on Windows. Is that a problem? (jk)</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 20, 2018 at 3:35 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Motivation:<br>1. Celery causes many bugs and issues for Pulp2 and 3 users and there is no end in sight.<br><br></div><div>2. The Pulp core team spends a lot of effort fixing Celery bugs. It's often times just us doing it with little or no assistance from the upstream communities. It's across 4 projects: celery, kombu, billiard, and pyamqp.<br></div><div><br>3. Celery will never allow a coverage report to be generated when pulp-smash runs because Celery forked the multiprocessing library into something called billiard. This will limit Pulp forever. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div></div><div><br>4. I don't want to work with Celery anymore and I think the other maintainers (@dalley, @daviddavis) may feel the same. It's an endless headache. Even basic things don't work in Celery regularly.<br></div><div><br></div><div>Proposed change: Replace Pulp3's usage of Celery with RQ (<a href="http://python-rq.org/" target="_blank">http://python-rq.org/</a>)<br><br></div><div>We would keep the exact same design of a resource manager with n workers, each worker pulling it's work exclusively from a dedicated queue. I've looked into porting pulp3 to it and it's doable because all the same concepts are there. There are a few details to work out, but I wanted to start the "should we" discussion before we do all-out technical planning.<br><br></div><div>When would we do this? I'm proposing soon. It doesn't need to block the beta, but soon would be good. I don't think users will care much except for their systemd files, but it is fundamental and important to pulp3 so we want to get it testing sooner.<br><br></div><div>Ideas, comments, questions are welcome!<br><br></div><div>Thanks,<br></div><div>Brian<br></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></div>