Feature #18596
closed
Config option to enable preemptible variants of all instance types
Added by Tom Clegg almost 3 years ago.
Updated over 2 years ago.
Release relationship:
Auto
Description
Currently, in order to use preemptible instances, the operator needs to add InstanceTypes entries for all instance types they hope to use, with the Preemptible flag set, and possibly a lower price. This is tedious.
In most cases it would be much more convenient to have a config option (PreemptiblePriceFactor?) that automatically duplicates every non-preemptible InstanceTypes entry that does not already have a preemptible counterpart, with a max/bid price of PreemptiblePriceFactor × Price of the non-preemptible variant.
It will be the job of the go config loader to add the additional preemptible variants to instance types.
- Related to Bug #18562: [api] should not change the preemptible flag across the board added
- Subject changed from Config option enable preemptible variants of all instance types to Config option to enable preemptible variants of all instance types
- Related to Idea #18179: Better spot instance support added
- Target version set to 2022-03-16 sprint
- Description updated (diff)
- Assigned To set to Tom Clegg
- Target version changed from 2022-03-16 sprint to 2022-03-30 Sprint
What should we do if the config has a non-zero PreemptiblePriceFactor and instance type "x" and instance type "x.preemptible" that differs from the one we'd add automatically? Warning and use the explicitly configured one? (Current branch will overwrite with the auto-generated one.)
- Status changed from New to In Progress
Tom Clegg wrote:
18596-preemptible-price-factor @ 7b2c2c415aa67936389998a5c93d52891e5644f4 -- developer-run-tests: #2972 
A few things:
- in autofillPreemptible, any existing preemptible node types that match our naming pattern will be silently overwritten. Should this be a
arvados-server config-check warning?
- in
lib/config/config.default.yml, is it worth pointing out that setting PreemptiblePriceFactor to 1 could be a good choice?
Thanks for that AnonymousToken bugfix! LGTM otherwise.
- Status changed from In Progress to Resolved
Applied in changeset arvados-private:commit:arvados|926f71e8481d62a20ff66a834d876713df5fd0c7.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by