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

Use market prices to determine regions to run in. #449

Open
jschwartzentruber opened this issue Jun 7, 2024 · 0 comments
Open

Use market prices to determine regions to run in. #449

jschwartzentruber opened this issue Jun 7, 2024 · 0 comments

Comments

@jschwartzentruber
Copy link
Contributor

When we migrated to Taskcluster we lost the ability to automatically run fuzzing in the cheapest regions at a given time (based on spot-market fluctuations).

Since fuzzing-decision generates a list of machine/region configurations in which tasks could run, we could periodically calculate which regions are currently the cheapest and use that to filter the list of configurations so we run in cheaper regions.

This would have a few moving pieces:

  1. Periodically scrape provider prices for machine/regions we use (both spot and demand pricing).
    • Machine specs are generated by fuzzing-decision based on a list of potential machines in fuzzing-tc-config.
    • Regions are pulled from community-tc-config which has to allocate static resources in each region it supports (subnets, security groups, etc.).
  2. Update fuzzing pools to utilize acceptable machines in the cheapest regions at the current time.
    • This affects future machine generation only. It doesn't kill currently running machines.
    • "Cheapest" needs a definition. (lower than mean?)
  3. Set a maximum price to avoid spot price fluctuations.
    • Spot providers support setting a bid price which will not be exceeded. We currently don't utilize this.
    • Setting it to x% above the current market price would prevent us from being affected by large price variations by preempting our machine if the price goes up. This would allow a new machine to be allocated using more recent price data.

We could get in a situation where we are preempted because of price fluctuations and don't re-run until the next fuzzing cycle. This can be mitigated by raising the threshold for "cheapest," by raising the threshold for max price, or by asking for additional regions in community-tc-config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant