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

Prioritize solver already based on requirements #2689

Open
1 task
harshad16 opened this issue Oct 27, 2022 · 2 comments
Open
1 task

Prioritize solver already based on requirements #2689

harshad16 opened this issue Oct 27, 2022 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/devsecops Categorizes an issue or PR as relevant to SIG DevSecOps.

Comments

@harshad16
Copy link
Member

harshad16 commented Oct 27, 2022

Is your feature request related to a problem? Please describe.
Our current model executes the solvers for packages at the same time.When a new solver is included, it brings in a lot of solvers execution to be done, based on the number of packages yet to be solved, which creates a bottle neck for the old solver.

For example:
Lets say:

  • pypi has 1million packages.
  • Thoth-station has three solvers, for say:
    • ubi8-py38
    • f34-py39
    • f35-py310
      And each solver is already enabled for execution. Assuming that all the solver have solved up to 98% of packages.
      Now in this mix, if we include ubi9-py39, then it would fill up the pipelines as they are more package yet to be solved.
      The package-release-job, would still look for new packages to solved, however they would be in queue.
      The wait of each solver depends on one another.

If we have consumer requesting a specific solver, we only have the option to halt the rest by removing them from the mix
and wait for the specific solver be up-to-date.

The goal is to find a solution for solver prioritization.

Describe the solution you'd like
None as of now.

Describe alternatives you've considered
Halting other solvers for specific solver.

Additional context

/priority important-longterm
/sig devsecops

Acceptance criteria

@harshad16 harshad16 added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 27, 2022
@sesheta sesheta added priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/devsecops Categorizes an issue or PR as relevant to SIG DevSecOps. labels Oct 27, 2022
@harshad16 harshad16 moved this to 🆕 New in Planning Board Oct 27, 2022
@harshad16
Copy link
Member Author

harshad16 commented Oct 27, 2022

Context from the tech call:

As we are running multiple solvers at the same time, it takes time for newer packages to sync for all the solvers. any suggestion on the changing the priority of this action:

  • select a set of solver that are most used (via configmap)
    • disable some solver(s)? concern: if we keep supporting them, we should keep solving
  • priority in solver workflow
    • idea: configmap with : map ?
  • changes in consumer logic, by having solver based topics and throttling of consumers?

Usage Statistic? Which (non integration tests) advises use what os+py?

How do we pick our focus?

Questions

  • are there particular components we could investigate to see if we have low hanging perf improvements possible to have faster solver/sync ?
    solvers, graph-refresh-job, package-release-job and investigator.

@harshad16
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/devsecops Categorizes an issue or PR as relevant to SIG DevSecOps.
Projects
Status: 🆕 New
Development

No branches or pull requests

2 participants