Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • S sysadm-environment
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 167
    • Issues 167
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Platform
  • Infrastructure
  • sysadm-environment
  • Issues
  • #3667
Closed
Open
Issue created Oct 18, 2021 by Antoine R. Dumont@ardumontOwner

Orchestrate origins scheduling according to scheduler metrics feedback

Currently the next-gen scheduler runners [1] for origins are triggered on each scheduler machine per environment [2]. So far, they are managed manually through a cli call for each type of visits (and eventually, once in a while per lister or forge, ...).

We need to replace those with a new module which does not exist yet, the orchestrator. That module would be in charge of recurringly schedule origins of a given type according to the scheduler metrics available. Deployment wise, that'd be a systemd service that would launch it.

Its scheduling algorithm would be something like:

for each visit type:
  - "check queue status":
      if below threshold for that queue:
        goto "fill-in the void state"
      else
        continue: "next visit type"
      end

  - "fill-in the void state":
    for each (randomly picked?) policy (according to ratio [3]) for that visit type:
      if room in the queue and origins to schedule for that policy:
        schedule origins: push messages in the queue
      elif room in the queue and no more origins to schedule for that policy:
        continue: "next policy"
      else ("no more room in the queue"):
        continue: "next visit type"
      end
    end for
end for
  • [1] scheduler runners are process in charge of recurringly schedule origins per visit type (and more if need be, e.g. lister-uuid, ...)

  • [2] root tmux session in:

  • prod: saatchi

  • staging: scheduler0

  • [3] Ratio could be:

|----------------------------------------------------------------+-----------------------------------+-------|
| visit_type                                                     | scheduling policies               | ratio |
|----------------------------------------------------------------+-----------------------------------+-------|
| package-loader: archive, cran, debian, npm, nixguix, pypi, ... | already_visited_order_by_lag      |    50 |
|                                                                | never_visited_oldest_update_first |    50 |
|----------------------------------------------------------------+-----------------------------------+-------|
| git, svn, hg                                                   | already_visited_order_by_lag      |    49 |
|                                                                | never_visited_oldest_update_first |    49 |
|                                                                | origins_without_last_update       |     2 |
|----------------------------------------------------------------+-----------------------------------+-------|

Migrated from T3667 (view on Phabricator)

Edited Oct 18, 2022 by Antoine R. Dumont
Assignee
Assign to
Time tracking