Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combine all schedulers for all organisations #3838

Open
jpbruinsslot opened this issue Nov 13, 2024 · 0 comments · May be fixed by #3839
Open

Combine all schedulers for all organisations #3838

jpbruinsslot opened this issue Nov 13, 2024 · 0 comments · May be fixed by #3839
Assignees
Labels
discussion mula Issues related to the scheduler scalability

Comments

@jpbruinsslot
Copy link
Contributor

jpbruinsslot commented Nov 13, 2024

Proposal

The current situation is that we create individual 'schedulers' for every organisation, this amounts to 3 schedulers for every organisation.

The addition of queues in the scheduler being persisted as a database table allows us to explore the possibility of running a dedicated schedulers for all organisations.

Create one BoefjeScheduler, NormalizerScheduler and ReportScheduler for all organisations instead of individual schedulers for every organisation. One message queue for all scan profile mutations to which scan profile mutations are posted of all organisations for the BoefjeScheduler, and one message queue for raw file creation of all organisations for the NormalizerScheduler, the ReportScheduler will reference its internal database table.

Advantages

  • Less overhead of creating and removing schedulers for every organisation
  • Stops continuous checking of available organisations
  • Allows to replicate scheduler application instances when used with a blocking messaging queue
  • Additionally we need to support popping multiple tasks from the endpoint

Disadvantages

  • the allow_updates, allow_replace, allow_priority_updates for individual organisations can't be used, however this function doesn't seem to be used and is for every type scheduler the same
  • we should investigate how we solve when organisations wan to disable a scheduler, and even if this has a use-case

Impact

  • now we have several different rabbitmq messaging queues for every organisation, this needs to be reduced to one
  • organisation ids need to be passed in the messages on the queue
  • changes to task runner to pop off tasks
  • rocky likely needs to be update to interface with changes from the scheduler api

PR

#3839

@jpbruinsslot jpbruinsslot added mula Issues related to the scheduler discussion scalability labels Nov 13, 2024
@jpbruinsslot jpbruinsslot added this to KAT Nov 13, 2024
@github-project-automation github-project-automation bot moved this to Incoming features / Need assessment in KAT Nov 13, 2024
@jpbruinsslot jpbruinsslot moved this from Incoming features / Need assessment to To be discussed in KAT Nov 13, 2024
@jpbruinsslot jpbruinsslot linked a pull request Nov 21, 2024 that will close this issue
9 tasks
@jpbruinsslot jpbruinsslot changed the title One scheduler type for all organisations Combine all schedulers for all organisations Nov 21, 2024
@Donnype Donnype moved this from To be discussed to Backlog / To do in KAT Dec 2, 2024
@jpbruinsslot jpbruinsslot moved this from Backlog / To do to In Progress in KAT Dec 3, 2024
@Donnype Donnype removed their assignment Dec 3, 2024
@jpbruinsslot jpbruinsslot moved this from In Progress to Review in KAT Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion mula Issues related to the scheduler scalability
Projects
Status: Review
Development

Successfully merging a pull request may close this issue.

3 participants