Ohad Levy <ohadl...@gmail.com> writes: > On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal <l...@redhat.com> wrote: > >> 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. >> > > I don't know if that's what you had in mind or not, but if it end up being > blocking the request, its not useful at all, as that would lead to more > confusion, and a developer will need to care for more usage cases (is it > blocking now, is it running async) and especially when there is a need for > ui, imho it just makes it harder. > > if we do move to active job api in core(+1), I could see us starting > without tasks first for pure async operations, over time converting dynflow > to be orchestration engine vs async and orchestration. > Futher, I would challenge a bit the orchestration implementation in Katello > (not in a negative way) but if a task fails due to unavailability of one of > the backends, the application should know how to deal with it (micro > service / soa) rather then fail / lock the task for the future, I would ask > if this is the correct long term approach for complex operations.
While I like challenging the things, let's not make this thread to broad. I've made quite a progress with ActiveJob, and while it's not perfect, for basic introduction of async operations it should work well enough. However, I'm still few days from having it ready, and I want keep the promise to propose the solution to falling nightlies by Monday evening. Therefore, I've opened a PR for reverting the original change https://github.com/theforeman/foreman/pull/4217 This is not a resignation of trying to get the tasks functionality into core, but rather lowering a pressure a bit so that we can focus on the right things to do. I hope the PR adding the functionality back, using the approach we talked about, will come sooner rather than later, followed by adding the tasking plumbing into core, to support async operations, as well as dynflow orchestration and current host orchestration. -- Ivan > > Ohad > > >> LZ >> >> On Fri, Jan 20, 2017 at 9:26 AM, Marek Hulán <mhu...@redhat.com> 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 <l...@redhat.com> 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 foreman-dev+unsubscr...@googlegroups.com. >> > 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 foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
