All PRs have Travis showing green and all necessary LGTMs. The plan is to merge next Tuesday the 15th, which means it will be in core Beta 4.
Yesterday, @dalley and I published a blog post which outlines the change for users along with a porting guide for plugins to port onto RQ as well. https://pulpproject.org/2018/05/08/pulp3-moving-to-rq/ Thank you to everyone for the help, collaboration, and energy on this significant change. On Mon, May 7, 2018 at 5:37 PM, Daniel Alley <dal...@redhat.com> wrote: > I've finished my review and resolved all of the 'blocker' issues that were > uncovered during testing. Overall, I'm highly confident that this is a > better path forwards than the continued use of Celery / Kombu. There are a > couple of outstanding edge cases to be resolved eventually, which I plan to > file as issues post-merge, but nothing serious or intractable. > > If there are no objections, I think it would be reasonable to merge this > code after this week's beta builds are published (after, in order to avoid > major changes during Summit / PyCon prep time). > > Thank you, Brian, for doing the planning and work needed to make this > happen. It was a lot of effort and is very highly appreciated. > > On Mon, Apr 30, 2018 at 8:28 AM, Brian Bouterse <bbout...@redhat.com> > wrote: > >> Through several rebases, now all PRs are showing the RQ PRs on Travis as >> passing with pulp-smash. Several points of feedback have been addressed. >> >> If you're interested in commenting on these PRs or trying them out, >> please do. I hope to merge after the other taking system maintainers >> @dalley and @daviddavis have finished their testing/review and barring any >> other calls for delay or blocking concerns. >> >> If there are any questions, issues, or concerns, please reach out, and we >> can talk through them. >> >> >> >> On Fri, Apr 20, 2018 at 4:18 PM, Brian Bouterse <bbout...@redhat.com> >> wrote: >> >>> I put together a prototype and posted the PRs. I'm still working to get >>> Travis happy, but locally 100% of smash tests using these branches. It's >>> worked very reliably for me so far. There are no gaps in the pulp feature >>> set on top of RQ. >>> >>> I hope people test it out and give some feedback. See the commit >>> messages for details on what was done. Here are the PRs: >>> >>> https://github.com/pulp/pulp/pull/3454 >>> https://github.com/pulp/pulp_file/pull/72 >>> https://github.com/pulp/devel/pull/146 >>> https://github.com/PulpQE/pulp-smash/pull/960 >>> >>> Feel free to send questions here or to the PR. Any feedback is welcome. >>> >>> -Brian >>> >>> >>> >>> >>> On Thu, Mar 22, 2018 at 5:28 PM, Milan Kovacik <mkova...@redhat.com> >>> wrote: >>> >>>> +1 I like RQ and I like http://python-rq.org/docs/testing/ esp. >>>> there's Fakeredis ;) >>>> >>>> >>>> -- >>>> milan >>>> >>>> >>>> On Thu, Mar 22, 2018 at 6:58 PM, Brian Bouterse <bbout...@redhat.com> >>>> wrote: >>>> > Thanks for all the discussion both on list and on irc. After more >>>> > investigation, it sounds like there are no feature gaps, but we will >>>> need to >>>> > incorporate this workaround to cancel a task that is already running. >>>> > >>>> > The feedback I've heard on the idea is that it's valuable and looks >>>> > feasible, but we won't really know until we prototype it a bit. Based >>>> on the >>>> > technical outline in the previous email, I believe it can be >>>> prototyped in a >>>> > day or two. I plan to do this soon, once I contribute to a few other >>>> > required-for-beta planning items first. I'll post my PR to see what >>>> other >>>> > think of the change, probably next week. >>>> > >>>> > >>>> > >>>> > On Wed, Mar 21, 2018 at 6:41 PM, Daniel Alley <dal...@redhat.com> >>>> wrote: >>>> >> >>>> >> I meant in the sense that, what is the aftermath when it comes back >>>> >> online, and is it screwed up in ways that cause side effects. >>>> >> >>>> >> On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet <jau...@redhat.com> >>>> wrote: >>>> >>> >>>> >>> > RQ does not support revoking tasks. If you send the worker a >>>> SIGINT, >>>> >>> > it will finish the task and then stop processing new ones. If >>>> you send the >>>> >>> > worker SIGKILL, it will stop immediately, but I don't think it >>>> gracefully >>>> >>> > handles this circumstance. >>>> >>> >>>> >>> Nothing handles SIGKILL gracefully. Processes can't catch that >>>> signal. >>>> >>> `kill -9 $pid` sends SIGKILL. >>>> >>> >>>> >>> If one is looking for a way to gracefully, immediately kill an RQ >>>> >>> worker, then SIGTERM may do the trick. Anecdotally, many processes >>>> >>> handle this signal in a hurried fashion. Semantically, this is >>>> >>> appropriate: SIGINT is the "terminal interrupt" signal (Ctrl+c sends >>>> >>> SIGINT), whereas SIGTERM is the "termination signal." >>>> >> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > Pulp-dev mailing list >>>> > Pulp-dev@redhat.com >>>> > https://www.redhat.com/mailman/listinfo/pulp-dev >>>> > >>>> >>> >>> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
