> which is closes to non distributed fashion you mentioned.
If you use Ignite Services I'd say it's already distributed.
How people often do automation: they pick a single server and setup a system
cron job there. The server dies - their cron doesn't run, which isn't how it
should be.
Now, if
Hey Stanislav,
Thanks for reference. I'll see how our cron-utils use combined with
ignite services will evolve. So far we're using it with node singletons,
which is closes to non distributed fashion you mentioned.
If we will end up building additional logic for it we'll definitely look
for cons
Hi Lukasz, Ilya,
I completely agree with Ilya that the core Ignite modules shouldn't deal with
that.
That said, I've seen numerous situations when people tried to implement
scheduling of tasks for Ignite.
Sometimes, they wouldn't do it in a distributed fashion, and it would because
the hosting
Hello Ilya,
Thank you for clarification. I wasn't aware schedule is on strike. ;-)
Mentioned cron-utils is something I used.
My intention was to reduce number of profiles needed to build ignite,
but if this module is marked for removal then both - an extra profile
and licensing inconsistency wi
Hello!
I suggest getting rid of ignite scheduler completely.
It is poorly thought out, not used by anyone, has a baroque and incomplete
API. In no way it is doing anything useful for out users in its current
form.
Yes we could rewrite it to be more useful, but I think Ignite is not a
distributed
