Giter Club home page Giter Club logo

Comments (7)

arvchristos avatar arvchristos commented on July 17, 2024 2

For me, it's not because it only moves the complexity to the user (so it increases the complexity needed to use IntelMQ, and as anything made by users, it's vulnerable to human errors ;)). And in fact, it looks like partially implemented feature (´scheduled´ type of running means nothing for IntelMQ).

I propose a little different solution than celery: for bots with the scheduled running type, add another configuration option with the schedule definition (e.g. in cron format; intelmqctl check should check syntax). Then, let a separate daemon be running in background, read this configuration periodically and ensure execution (e.g. using https://github.com/agronholm/apscheduler). I think it should be rather simple and flexible solution, with a possibility to even replace the scheduler with different solution (if you prefer e.g. generating crontab instead).

Thank you for the input @kamil-certat . Actually what you describe is more or less what I had in mind with Celery, bots would have a config parameter for scheduled runs. I suggested Celery mainly because it has a programmatic interface for this as well as it is battle tested.

I hope life permits and I can come up with the time soon to write the IEP @aaronkaplan !

from intelmq.

arvchristos avatar arvchristos commented on July 17, 2024 1

I totally agree that this feature would make user's life much easier (also on the documentation/standardization of IntelMQ deployments). I can see that it will add more code surface to the project but solutions like Celery (pretty mature + compatible with current IntelMQ stack) for scheduling could introduce many new use-cases and features for bots.

This also means that we would not be differentiating set ups according to the existence of systemd or dockerization. Instead there would be a unified approach in terms of deployment and configuration.

from intelmq.

aaronkaplan avatar aaronkaplan commented on July 17, 2024

Not sure if I think this is good. Why?

  • leave scheduling to the program which was made for it (cron , etc.) . Do not try to add that complexity to intelmq
  • it adds code and complexity

But I see the need for something like that (maybe another type of cron) inside of docker.

from intelmq.

kamil-certat avatar kamil-certat commented on July 17, 2024

I understand your point, but I believe it - when implemented properly - would remove complexity rather than adding it. Leaving such an important feature to be manages outside the IntelMQ adds a significant complexity for users. I think it's reasonable to expect IntelMQ to handle it; on the other hand, we could also leave starting normal bots to user and do not support it through API/CLI - with just saying that it's a complexity. ;)

However, this issue is so far more a reminder - a solution should be carefully designed, keeping the simplicity in mind. You know, I suggested using Python-native solutions, but an alternative would be to e.g. configure underlying program (cron, systemd, etc.), taking away the manual task from user without deep changes.

from intelmq.

aaronkaplan avatar aaronkaplan commented on July 17, 2024

@arvchristos could you maybe sketch out how you would see an IntelMQ + celery integration? Like as in an IEP?

from intelmq.

aaronkaplan avatar aaronkaplan commented on July 17, 2024

Maybe I should be a bit more verbose why my original answer was that I was afraid of adding complexity:
because we already have a mechanism to run bots once (one-shot) only. So, if we use that config option + schedule them via cronjob, then I would say that's the simplest way of achieving that. No?

from intelmq.

kamil-certat avatar kamil-certat commented on July 17, 2024

For me, it's not because it only moves the complexity to the user (so it increases the complexity needed to use IntelMQ, and as anything made by users, it's vulnerable to human errors ;)). And in fact, it looks like partially implemented feature (´scheduled´ type of running means nothing for IntelMQ).

I propose a little different solution than celery: for bots with the scheduled running type, add another configuration option with the schedule definition (e.g. in cron format; intelmqctl check should check syntax). Then, let a separate daemon be running in background, read this configuration periodically and ensure execution (e.g. using https://github.com/agronholm/apscheduler). I think it should be rather simple and flexible solution, with a possibility to even replace the scheduler with different solution (if you prefer e.g. generating crontab instead).

from intelmq.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.