#[non_exhaustive]pub struct SpotOptions {
pub allocation_strategy: Option<SpotAllocationStrategy>,
pub maintenance_strategies: Option<FleetSpotMaintenanceStrategies>,
pub instance_interruption_behavior: Option<SpotInstanceInterruptionBehavior>,
pub instance_pools_to_use_count: Option<i32>,
pub single_instance_type: Option<bool>,
pub single_availability_zone: Option<bool>,
pub min_target_capacity: Option<i32>,
pub max_total_price: Option<String>,
}
Expand description
Describes the configuration of Spot Instances in an EC2 Fleet.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. }
syntax; cannot be matched against without a wildcard ..
; and struct update syntax will not work.allocation_strategy: Option<SpotAllocationStrategy>
The strategy that determines how to allocate the target Spot Instance capacity across the Spot Instance pools specified by the EC2 Fleet launch configuration. For more information, see Allocation strategies for Spot Instances in the Amazon EC2 User Guide.
- price-capacity-optimized (recommended)
-
EC2 Fleet identifies the pools with the highest capacity availability for the number of instances that are launching. This means that we will request Spot Instances from the pools that we believe have the lowest chance of interruption in the near term. EC2 Fleet then requests Spot Instances from the lowest priced of these pools.
- capacity-optimized
-
EC2 Fleet identifies the pools with the highest capacity availability for the number of instances that are launching. This means that we will request Spot Instances from the pools that we believe have the lowest chance of interruption in the near term. To give certain instance types a higher chance of launching first, use
capacity-optimized-prioritized
. Set a priority for each instance type by using thePriority
parameter forLaunchTemplateOverrides
. You can assign the same priority to differentLaunchTemplateOverrides
. EC2 implements the priorities on a best-effort basis, but optimizes for capacity first.capacity-optimized-prioritized
is supported only if your EC2 Fleet uses a launch template. Note that if the On-DemandAllocationStrategy
is set toprioritized
, the same priority is applied when fulfilling On-Demand capacity. - diversified
-
EC2 Fleet requests instances from all of the Spot Instance pools that you specify.
- lowest-price (not recommended)
-
We don't recommend the
lowest-price
allocation strategy because it has the highest risk of interruption for your Spot Instances.EC2 Fleet requests instances from the lowest priced Spot Instance pool that has available capacity. If the lowest priced pool doesn't have available capacity, the Spot Instances come from the next lowest priced pool that has available capacity. If a pool runs out of capacity before fulfilling your desired capacity, EC2 Fleet will continue to fulfill your request by drawing from the next lowest priced pool. To ensure that your desired capacity is met, you might receive Spot Instances from several pools. Because this strategy only considers instance price and not capacity availability, it might lead to high interruption rates.
Default: lowest-price
maintenance_strategies: Option<FleetSpotMaintenanceStrategies>
The strategies for managing your workloads on your Spot Instances that will be interrupted. Currently only the capacity rebalance strategy is available.
instance_interruption_behavior: Option<SpotInstanceInterruptionBehavior>
The behavior when a Spot Instance is interrupted.
Default: terminate
instance_pools_to_use_count: Option<i32>
The number of Spot pools across which to allocate your target Spot capacity. Supported only when AllocationStrategy
is set to lowest-price
. EC2 Fleet selects the cheapest Spot pools and evenly allocates your target Spot capacity across the number of Spot pools that you specify.
Note that EC2 Fleet attempts to draw Spot Instances from the number of pools that you specify on a best effort basis. If a pool runs out of Spot capacity before fulfilling your target capacity, EC2 Fleet will continue to fulfill your request by drawing from the next cheapest pool. To ensure that your target capacity is met, you might receive Spot Instances from more than the number of pools that you specified. Similarly, if most of the pools have no Spot capacity, you might receive your full target capacity from fewer than the number of pools that you specified.
single_instance_type: Option<bool>
Indicates that the fleet uses a single instance type to launch all Spot Instances in the fleet.
Supported only for fleets of type instant
.
single_availability_zone: Option<bool>
Indicates that the fleet launches all Spot Instances into a single Availability Zone.
Supported only for fleets of type instant
.
min_target_capacity: Option<i32>
The minimum target capacity for Spot Instances in the fleet. If this minimum capacity isn't reached, no instances are launched.
Constraints: Maximum value of 1000
. Supported only for fleets of type instant
.
At least one of the following must be specified: SingleAvailabilityZone
| SingleInstanceType
max_total_price: Option<String>
The maximum amount per hour for Spot Instances that you're willing to pay. We do not recommend using this parameter because it can lead to increased interruptions. If you do not specify this parameter, you will pay the current Spot price.
If you specify a maximum price, your Spot Instances will be interrupted more frequently than if you do not specify this parameter.
If your fleet includes T instances that are configured as unlimited
, and if their average CPU usage exceeds the baseline utilization, you will incur a charge for surplus credits. The maxTotalPrice
does not account for surplus credits, and, if you use surplus credits, your final cost might be higher than what you specified for maxTotalPrice
. For more information, see Surplus credits can incur charges in the Amazon EC2 User Guide.
Implementations§
Source§impl SpotOptions
impl SpotOptions
Sourcepub fn allocation_strategy(&self) -> Option<&SpotAllocationStrategy>
pub fn allocation_strategy(&self) -> Option<&SpotAllocationStrategy>
The strategy that determines how to allocate the target Spot Instance capacity across the Spot Instance pools specified by the EC2 Fleet launch configuration. For more information, see Allocation strategies for Spot Instances in the Amazon EC2 User Guide.
- price-capacity-optimized (recommended)
-
EC2 Fleet identifies the pools with the highest capacity availability for the number of instances that are launching. This means that we will request Spot Instances from the pools that we believe have the lowest chance of interruption in the near term. EC2 Fleet then requests Spot Instances from the lowest priced of these pools.
- capacity-optimized
-
EC2 Fleet identifies the pools with the highest capacity availability for the number of instances that are launching. This means that we will request Spot Instances from the pools that we believe have the lowest chance of interruption in the near term. To give certain instance types a higher chance of launching first, use
capacity-optimized-prioritized
. Set a priority for each instance type by using thePriority
parameter forLaunchTemplateOverrides
. You can assign the same priority to differentLaunchTemplateOverrides
. EC2 implements the priorities on a best-effort basis, but optimizes for capacity first.capacity-optimized-prioritized
is supported only if your EC2 Fleet uses a launch template. Note that if the On-DemandAllocationStrategy
is set toprioritized
, the same priority is applied when fulfilling On-Demand capacity. - diversified
-
EC2 Fleet requests instances from all of the Spot Instance pools that you specify.
- lowest-price (not recommended)
-
We don't recommend the
lowest-price
allocation strategy because it has the highest risk of interruption for your Spot Instances.EC2 Fleet requests instances from the lowest priced Spot Instance pool that has available capacity. If the lowest priced pool doesn't have available capacity, the Spot Instances come from the next lowest priced pool that has available capacity. If a pool runs out of capacity before fulfilling your desired capacity, EC2 Fleet will continue to fulfill your request by drawing from the next lowest priced pool. To ensure that your desired capacity is met, you might receive Spot Instances from several pools. Because this strategy only considers instance price and not capacity availability, it might lead to high interruption rates.
Default: lowest-price
Sourcepub fn maintenance_strategies(&self) -> Option<&FleetSpotMaintenanceStrategies>
pub fn maintenance_strategies(&self) -> Option<&FleetSpotMaintenanceStrategies>
The strategies for managing your workloads on your Spot Instances that will be interrupted. Currently only the capacity rebalance strategy is available.
Sourcepub fn instance_interruption_behavior(
&self,
) -> Option<&SpotInstanceInterruptionBehavior>
pub fn instance_interruption_behavior( &self, ) -> Option<&SpotInstanceInterruptionBehavior>
The behavior when a Spot Instance is interrupted.
Default: terminate
Sourcepub fn instance_pools_to_use_count(&self) -> Option<i32>
pub fn instance_pools_to_use_count(&self) -> Option<i32>
The number of Spot pools across which to allocate your target Spot capacity. Supported only when AllocationStrategy
is set to lowest-price
. EC2 Fleet selects the cheapest Spot pools and evenly allocates your target Spot capacity across the number of Spot pools that you specify.
Note that EC2 Fleet attempts to draw Spot Instances from the number of pools that you specify on a best effort basis. If a pool runs out of Spot capacity before fulfilling your target capacity, EC2 Fleet will continue to fulfill your request by drawing from the next cheapest pool. To ensure that your target capacity is met, you might receive Spot Instances from more than the number of pools that you specified. Similarly, if most of the pools have no Spot capacity, you might receive your full target capacity from fewer than the number of pools that you specified.
Sourcepub fn single_instance_type(&self) -> Option<bool>
pub fn single_instance_type(&self) -> Option<bool>
Indicates that the fleet uses a single instance type to launch all Spot Instances in the fleet.
Supported only for fleets of type instant
.
Sourcepub fn single_availability_zone(&self) -> Option<bool>
pub fn single_availability_zone(&self) -> Option<bool>
Indicates that the fleet launches all Spot Instances into a single Availability Zone.
Supported only for fleets of type instant
.
Sourcepub fn min_target_capacity(&self) -> Option<i32>
pub fn min_target_capacity(&self) -> Option<i32>
The minimum target capacity for Spot Instances in the fleet. If this minimum capacity isn't reached, no instances are launched.
Constraints: Maximum value of 1000
. Supported only for fleets of type instant
.
At least one of the following must be specified: SingleAvailabilityZone
| SingleInstanceType
Sourcepub fn max_total_price(&self) -> Option<&str>
pub fn max_total_price(&self) -> Option<&str>
The maximum amount per hour for Spot Instances that you're willing to pay. We do not recommend using this parameter because it can lead to increased interruptions. If you do not specify this parameter, you will pay the current Spot price.
If you specify a maximum price, your Spot Instances will be interrupted more frequently than if you do not specify this parameter.
If your fleet includes T instances that are configured as unlimited
, and if their average CPU usage exceeds the baseline utilization, you will incur a charge for surplus credits. The maxTotalPrice
does not account for surplus credits, and, if you use surplus credits, your final cost might be higher than what you specified for maxTotalPrice
. For more information, see Surplus credits can incur charges in the Amazon EC2 User Guide.
Source§impl SpotOptions
impl SpotOptions
Sourcepub fn builder() -> SpotOptionsBuilder
pub fn builder() -> SpotOptionsBuilder
Creates a new builder-style object to manufacture SpotOptions
.
Trait Implementations§
Source§impl Clone for SpotOptions
impl Clone for SpotOptions
Source§fn clone(&self) -> SpotOptions
fn clone(&self) -> SpotOptions
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for SpotOptions
impl Debug for SpotOptions
Source§impl PartialEq for SpotOptions
impl PartialEq for SpotOptions
impl StructuralPartialEq for SpotOptions
Auto Trait Implementations§
impl Freeze for SpotOptions
impl RefUnwindSafe for SpotOptions
impl Send for SpotOptions
impl Sync for SpotOptions
impl Unpin for SpotOptions
impl UnwindSafe for SpotOptions
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left
is true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left(&self)
returns true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the foreground set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red()
and
green()
, which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg()
:
use yansi::{Paint, Color};
painted.fg(Color::White);
Set foreground color to white using white()
.
use yansi::Paint;
painted.white();
Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the background set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red()
and
on_green()
, which have the same functionality but
are pithier.
§Example
Set background color to red using fg()
:
use yansi::{Paint, Color};
painted.bg(Color::Red);
Set background color to red using on_red()
.
use yansi::Paint;
painted.on_red();
Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute
value
.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold()
and
underline()
, which have the same functionality
but are pithier.
§Example
Make text bold using attr()
:
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);
Make text bold using using bold()
.
use yansi::Paint;
painted.bold();
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi
Quirk
value
.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask()
and
wrap()
, which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk()
:
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);
Enable wrapping using wrap()
.
use yansi::Paint;
painted.wrap();
Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition
value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted
only when both stdout
and stderr
are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);