On Wed, Jan 25, 2017 at 12:38 PM, Lukas Zapletal wrote:
> I like the idea of having plain ActiveJob for simple background tasks
> and providing tasks/dynflow for complex orchestration processes (also
> available via ActiveJob API). While I understand whole motivation why
> dynflow/task was created
I like the idea of having plain ActiveJob for simple background tasks
and providing tasks/dynflow for complex orchestration processes (also
available via ActiveJob API). While I understand whole motivation why
dynflow/task was created in the first place (providing a way to do
one-way orchestrations
Ohad Levy writes:
> On Tue, Jan 24, 2017 at 9:51 AM, Ivan Necas wrote:
>
>> Ewoud Kohl van Wijngaarden writes:
>>
>> > On Tue, Jan 24, 2017 at 12:10:34AM +0100, Ivan Necas wrote:
>> >> Ohad Levy writes:
>> >>
>> >> > On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal
>> wrote:
>> >> >
>> >> >> W
On Tue, Jan 24, 2017 at 9:51 AM, Ivan Necas wrote:
> Ewoud Kohl van Wijngaarden writes:
>
> > On Tue, Jan 24, 2017 at 12:10:34AM +0100, Ivan Necas wrote:
> >> Ohad Levy writes:
> >>
> >> > On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal
> wrote:
> >> >
> >> >> Why we haven't considered ActiveJ
Ewoud Kohl van Wijngaarden writes:
> On Tue, Jan 24, 2017 at 12:10:34AM +0100, Ivan Necas wrote:
>> Ohad Levy writes:
>>
>> > On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal wrote:
>> >
>> >> Why we haven't considered ActiveJob API in the first place? This looks
>> >> like ideal solution, easy
On Tue, Jan 24, 2017 at 12:10:34AM +0100, Ivan Necas wrote:
> Ohad Levy writes:
>
> > On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal wrote:
> >
> >> Why we haven't considered ActiveJob API in the first place? This looks
> >> like ideal solution, easy development and documented API.
> >>
> >> Ca
Ohad Levy writes:
> On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal 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
>> execu
On Fri, Jan 20, 2017 at 7:14 PM, Lukas Zapletal 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
Lukas Zapletal writes:
> 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 insid
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
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 writes:
> > >> I'm not sure I follow what you mean by administrative tasks. Note that
> > >> reports
> > >> import and puppet envs import are core
On Thu, Jan 19, 2017 at 06:04:58PM +0100, Ivan Necas wrote:
> Lukas Zapletal 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
Lukas Zapletal 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
>
> 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 progres
Few comments below
On čtvrtek 5. ledna 2017 15:25:47 CET Lukas Zapletal wrote:
> Is it only the Rails App that depends on Foreman Core? What's reasonable
> plan to me is:
>
> a) Extract core part that does not depend on Foreman core into a simple gem
> (that's what you propose I guess) and make i
Is it only the Rails App that depends on Foreman Core? What's reasonable
plan to me is:
a) Extract core part that does not depend on Foreman core into a simple gem
(that's what you propose I guess) and make it a hard dependency of core.
b) The rest of foreman-tasks (Rails App/Engine - administrati
On Wed, Jan 4, 2017 at 4:29 AM, Ivan Necas wrote:
> Hello friends,
>
> You've might noticed we started using foreman-tasks inside the
> foreman-core since [1] was merged. Unfortunately, we hit issues in the
> packaging phase and the proposed workarounds were not accepted ([2]
> [3]).
>
> Based on
+1
--
Marek
On středa 4. ledna 2017 10:29:19 CET Ivan Necas wrote:
> Hello friends,
>
> You've might noticed we started using foreman-tasks inside the
> foreman-core since [1] was merged. Unfortunately, we hit issues in the
> packaging phase and the proposed workarounds were not accepted ([2]
>
Hi,
On Wed, Jan 04, 2017 at 10:29:19AM +0100, Ivan Necas wrote:
> In the mean time, I would like to kindly ask for trying to
> find an acceptable workaround in [2] and [3] until this is done.
>
> [...]
>
> [2] - https://github.com/theforeman/foreman-packaging/pull/1436
> [3] - https://github.com/
Hello friends,
You've might noticed we started using foreman-tasks inside the
foreman-core since [1] was merged. Unfortunately, we hit issues in the
packaging phase and the proposed workarounds were not accepted ([2]
[3]).
Based on various discussions, as well as on the fact that
foreman-tasks is
20 matches
Mail list logo
