Why we haven't considered ActiveJob API in the first place? This looks like ideal solution, easy development and documented API.
Can't ActiveJob help us with memory issues we have with external task executor in Katello? I mean what if we run background tasks inside passenger process by default for easier deployment and maintenance. Of course, restart would mean lost queue. LZ On Fri, Jan 20, 2017 at 9:26 AM, Marek Hulán <[email protected]> wrote: > On pátek 20. ledna 2017 2:51:06 CET Ewoud Kohl van Wijngaarden wrote: >> On Thu, Jan 19, 2017 at 06:04:58PM +0100, Ivan Necas wrote: >> > Lukas Zapletal <[email protected]> writes: >> > >> I'm not sure I follow what you mean by administrative tasks. Note that >> > >> reports >> > >> import and puppet envs import are core actiones that now run as a >> > >> foreman >> > >> task >> > >> (both synchronous and asynchronous variants). By making the UI part >> > >> optional >> > >> users would not be able to monitor their progress, cancel them etc if >> > >> they >> > >> don't install the plugin. What would be the benefit of such setup? >> > > >> > > I am not telling not to ship it, but making it optional (but installed >> > > by >> > > default). Assuming that processes would work normally without the UI >> > > part. >> > > >> > > Other option is to simply move the UI into core, I don't think we should >> > > make our decomposition effort a dogma. Let's be realistic. >> > > >> > > Benefit? Solving the stalemate perhaps :-) >> > >> > So the latest updates updates if you don't follow the packaging PR [1] >> > >> > The goal right now is to: >> > 1. unblock the nightlies >> > 2. keep the async operations possible >> > 3. prefer proper way over hacks >> > >> > Although the goal is to get the foreman-tasks functionality to the core, >> > I don't think we can effort blocking nightlies much longer. To preserve >> > the async possibility there. >> > >> > I'm looking into leveraging ActiveJob interface to define the async >> > operations we added. The idea is: when there is no foreman-tasks, the >> > in-thread executor, that already is build into Rails, will be used, and >> > from the end user, it will behave as before. >> > >> > However, when foreman-tasks will be around and configured to be used for >> > async processing, the operation will go though that. >> > >> > Once this would be done, we could start adding the UI around async >> > operations directly to the core: so the foreman-tasks functionality >> > would be gradually moved to the core this way: once the core is given >> > certain functionality, it can be removed from the tasks. >> > >> > The important thing here is we could work on enhancing tasking >> > infrastructure in core while still supporting the current foreman-tasks >> > users and delivering enhancements there in the meantime. >> > >> > I'm setting the deadline for this on Monday EOB. If by that time turns >> > our this plan is not feasible, we would need to sacrifice goal 1., 2. or >> > 3. >> >> To me this sounds like a good plan. > > +1 > > If active job does not work we could also fallback to something like > `if defined?(ForemanTask)` and keep working on active job alternative. > > -- > Marek > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
