Struct ModifyCacheClusterInputBuilder

Source
#[non_exhaustive]
pub struct ModifyCacheClusterInputBuilder { /* private fields */ }
Expand description

A builder for ModifyCacheClusterInput.

Implementations§

Source§

impl ModifyCacheClusterInputBuilder

Source

pub fn cache_cluster_id(self, input: impl Into<String>) -> Self

The cluster identifier. This value is stored as a lowercase string.

This field is required.
Source

pub fn set_cache_cluster_id(self, input: Option<String>) -> Self

The cluster identifier. This value is stored as a lowercase string.

Source

pub fn get_cache_cluster_id(&self) -> &Option<String>

The cluster identifier. This value is stored as a lowercase string.

Source

pub fn num_cache_nodes(self, input: i32) -> Self

The number of cache nodes that the cluster should have. If the value for NumCacheNodes is greater than the sum of the number of current cache nodes and the number of cache nodes pending creation (which may be zero), more nodes are added. If the value is less than the number of existing cache nodes, nodes are removed. If the value is equal to the number of current cache nodes, any pending add or remove requests are canceled.

If you are removing cache nodes, you must use the CacheNodeIdsToRemove parameter to provide the IDs of the specific cache nodes to remove.

For clusters running Valkey or Redis OSS, this value must be 1. For clusters running Memcached, this value must be between 1 and 40.

Adding or removing Memcached cache nodes can be applied immediately or as a pending operation (see ApplyImmediately).

A pending operation to modify the number of cache nodes in a cluster during its maintenance window, whether by adding or removing nodes in accordance with the scale out architecture, is not queued. The customer's latest request to add or remove nodes to the cluster overrides any previous pending operations to modify the number of cache nodes in the cluster. For example, a request to remove 2 nodes would override a previous pending operation to remove 3 nodes. Similarly, a request to add 2 nodes would override a previous pending operation to remove 3 nodes and vice versa. As Memcached cache nodes may now be provisioned in different Availability Zones with flexible cache node placement, a request to add nodes does not automatically override a previous pending operation to add nodes. The customer can modify the previous pending operation to add more nodes or explicitly cancel the pending request and retry the new request. To cancel pending operations to modify the number of cache nodes in a cluster, use the ModifyCacheCluster request and set NumCacheNodes equal to the number of cache nodes currently in the cluster.

Source

pub fn set_num_cache_nodes(self, input: Option<i32>) -> Self

The number of cache nodes that the cluster should have. If the value for NumCacheNodes is greater than the sum of the number of current cache nodes and the number of cache nodes pending creation (which may be zero), more nodes are added. If the value is less than the number of existing cache nodes, nodes are removed. If the value is equal to the number of current cache nodes, any pending add or remove requests are canceled.

If you are removing cache nodes, you must use the CacheNodeIdsToRemove parameter to provide the IDs of the specific cache nodes to remove.

For clusters running Valkey or Redis OSS, this value must be 1. For clusters running Memcached, this value must be between 1 and 40.

Adding or removing Memcached cache nodes can be applied immediately or as a pending operation (see ApplyImmediately).

A pending operation to modify the number of cache nodes in a cluster during its maintenance window, whether by adding or removing nodes in accordance with the scale out architecture, is not queued. The customer's latest request to add or remove nodes to the cluster overrides any previous pending operations to modify the number of cache nodes in the cluster. For example, a request to remove 2 nodes would override a previous pending operation to remove 3 nodes. Similarly, a request to add 2 nodes would override a previous pending operation to remove 3 nodes and vice versa. As Memcached cache nodes may now be provisioned in different Availability Zones with flexible cache node placement, a request to add nodes does not automatically override a previous pending operation to add nodes. The customer can modify the previous pending operation to add more nodes or explicitly cancel the pending request and retry the new request. To cancel pending operations to modify the number of cache nodes in a cluster, use the ModifyCacheCluster request and set NumCacheNodes equal to the number of cache nodes currently in the cluster.

Source

pub fn get_num_cache_nodes(&self) -> &Option<i32>

The number of cache nodes that the cluster should have. If the value for NumCacheNodes is greater than the sum of the number of current cache nodes and the number of cache nodes pending creation (which may be zero), more nodes are added. If the value is less than the number of existing cache nodes, nodes are removed. If the value is equal to the number of current cache nodes, any pending add or remove requests are canceled.

If you are removing cache nodes, you must use the CacheNodeIdsToRemove parameter to provide the IDs of the specific cache nodes to remove.

For clusters running Valkey or Redis OSS, this value must be 1. For clusters running Memcached, this value must be between 1 and 40.

Adding or removing Memcached cache nodes can be applied immediately or as a pending operation (see ApplyImmediately).

A pending operation to modify the number of cache nodes in a cluster during its maintenance window, whether by adding or removing nodes in accordance with the scale out architecture, is not queued. The customer's latest request to add or remove nodes to the cluster overrides any previous pending operations to modify the number of cache nodes in the cluster. For example, a request to remove 2 nodes would override a previous pending operation to remove 3 nodes. Similarly, a request to add 2 nodes would override a previous pending operation to remove 3 nodes and vice versa. As Memcached cache nodes may now be provisioned in different Availability Zones with flexible cache node placement, a request to add nodes does not automatically override a previous pending operation to add nodes. The customer can modify the previous pending operation to add more nodes or explicitly cancel the pending request and retry the new request. To cancel pending operations to modify the number of cache nodes in a cluster, use the ModifyCacheCluster request and set NumCacheNodes equal to the number of cache nodes currently in the cluster.

Source

pub fn cache_node_ids_to_remove(self, input: impl Into<String>) -> Self

Appends an item to cache_node_ids_to_remove.

To override the contents of this collection use set_cache_node_ids_to_remove.

A list of cache node IDs to be removed. A node ID is a numeric identifier (0001, 0002, etc.). This parameter is only valid when NumCacheNodes is less than the existing number of cache nodes. The number of cache node IDs supplied in this parameter must match the difference between the existing number of cache nodes in the cluster or pending cache nodes, whichever is greater, and the value of NumCacheNodes in the request.

For example: If you have 3 active cache nodes, 7 pending cache nodes, and the number of cache nodes in this ModifyCacheCluster call is 5, you must list 2 (7 - 5) cache node IDs to remove.

Source

pub fn set_cache_node_ids_to_remove(self, input: Option<Vec<String>>) -> Self

A list of cache node IDs to be removed. A node ID is a numeric identifier (0001, 0002, etc.). This parameter is only valid when NumCacheNodes is less than the existing number of cache nodes. The number of cache node IDs supplied in this parameter must match the difference between the existing number of cache nodes in the cluster or pending cache nodes, whichever is greater, and the value of NumCacheNodes in the request.

For example: If you have 3 active cache nodes, 7 pending cache nodes, and the number of cache nodes in this ModifyCacheCluster call is 5, you must list 2 (7 - 5) cache node IDs to remove.

Source

pub fn get_cache_node_ids_to_remove(&self) -> &Option<Vec<String>>

A list of cache node IDs to be removed. A node ID is a numeric identifier (0001, 0002, etc.). This parameter is only valid when NumCacheNodes is less than the existing number of cache nodes. The number of cache node IDs supplied in this parameter must match the difference between the existing number of cache nodes in the cluster or pending cache nodes, whichever is greater, and the value of NumCacheNodes in the request.

For example: If you have 3 active cache nodes, 7 pending cache nodes, and the number of cache nodes in this ModifyCacheCluster call is 5, you must list 2 (7 - 5) cache node IDs to remove.

Source

pub fn az_mode(self, input: AzMode) -> Self

Specifies whether the new nodes in this Memcached cluster are all created in a single Availability Zone or created across multiple Availability Zones.

Valid values: single-az | cross-az.

This option is only supported for Memcached clusters.

You cannot specify single-az if the Memcached cluster already has cache nodes in different Availability Zones. If cross-az is specified, existing Memcached nodes remain in their current Availability Zone.

Only newly created nodes are located in different Availability Zones.

Source

pub fn set_az_mode(self, input: Option<AzMode>) -> Self

Specifies whether the new nodes in this Memcached cluster are all created in a single Availability Zone or created across multiple Availability Zones.

Valid values: single-az | cross-az.

This option is only supported for Memcached clusters.

You cannot specify single-az if the Memcached cluster already has cache nodes in different Availability Zones. If cross-az is specified, existing Memcached nodes remain in their current Availability Zone.

Only newly created nodes are located in different Availability Zones.

Source

pub fn get_az_mode(&self) -> &Option<AzMode>

Specifies whether the new nodes in this Memcached cluster are all created in a single Availability Zone or created across multiple Availability Zones.

Valid values: single-az | cross-az.

This option is only supported for Memcached clusters.

You cannot specify single-az if the Memcached cluster already has cache nodes in different Availability Zones. If cross-az is specified, existing Memcached nodes remain in their current Availability Zone.

Only newly created nodes are located in different Availability Zones.

Source

pub fn new_availability_zones(self, input: impl Into<String>) -> Self

Appends an item to new_availability_zones.

To override the contents of this collection use set_new_availability_zones.

This option is only supported on Memcached clusters.

The list of Availability Zones where the new Memcached cache nodes are created.

This parameter is only valid when NumCacheNodes in the request is greater than the sum of the number of active cache nodes and the number of cache nodes pending creation (which may be zero). The number of Availability Zones supplied in this list must match the cache nodes being added in this request.

Scenarios:

  • Scenario 1: You have 3 active nodes and wish to add 2 nodes. Specify NumCacheNodes=5 (3 + 2) and optionally specify two Availability Zones for the two new nodes.

  • Scenario 2: You have 3 active nodes and 2 nodes pending creation (from the scenario 1 call) and want to add 1 more node. Specify NumCacheNodes=6 ((3 + 2) + 1) and optionally specify an Availability Zone for the new node.

  • Scenario 3: You want to cancel all pending operations. Specify NumCacheNodes=3 to cancel all pending operations.

The Availability Zone placement of nodes pending creation cannot be modified. If you wish to cancel any nodes pending creation, add 0 nodes by setting NumCacheNodes to the number of current nodes.

If cross-az is specified, existing Memcached nodes remain in their current Availability Zone. Only newly created nodes can be located in different Availability Zones. For guidance on how to move existing Memcached nodes to different Availability Zones, see the Availability Zone Considerations section of Cache Node Considerations for Memcached.

Impact of new add/remove requests upon pending requests

  • Scenario-1

    • Pending Action: Delete

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending delete.

  • Scenario-2

    • Pending Action: Delete

    • New Request: Create

    • Result: The new create, pending or immediate, replaces the pending delete.

  • Scenario-3

    • Pending Action: Create

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending create.

  • Scenario-4

    • Pending Action: Create

    • New Request: Create

    • Result: The new create is added to the pending create.

      Important: If the new create request is Apply Immediately - Yes, all creates are performed immediately. If the new create request is Apply Immediately - No, all creates are pending.

Source

pub fn set_new_availability_zones(self, input: Option<Vec<String>>) -> Self

This option is only supported on Memcached clusters.

The list of Availability Zones where the new Memcached cache nodes are created.

This parameter is only valid when NumCacheNodes in the request is greater than the sum of the number of active cache nodes and the number of cache nodes pending creation (which may be zero). The number of Availability Zones supplied in this list must match the cache nodes being added in this request.

Scenarios:

  • Scenario 1: You have 3 active nodes and wish to add 2 nodes. Specify NumCacheNodes=5 (3 + 2) and optionally specify two Availability Zones for the two new nodes.

  • Scenario 2: You have 3 active nodes and 2 nodes pending creation (from the scenario 1 call) and want to add 1 more node. Specify NumCacheNodes=6 ((3 + 2) + 1) and optionally specify an Availability Zone for the new node.

  • Scenario 3: You want to cancel all pending operations. Specify NumCacheNodes=3 to cancel all pending operations.

The Availability Zone placement of nodes pending creation cannot be modified. If you wish to cancel any nodes pending creation, add 0 nodes by setting NumCacheNodes to the number of current nodes.

If cross-az is specified, existing Memcached nodes remain in their current Availability Zone. Only newly created nodes can be located in different Availability Zones. For guidance on how to move existing Memcached nodes to different Availability Zones, see the Availability Zone Considerations section of Cache Node Considerations for Memcached.

Impact of new add/remove requests upon pending requests

  • Scenario-1

    • Pending Action: Delete

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending delete.

  • Scenario-2

    • Pending Action: Delete

    • New Request: Create

    • Result: The new create, pending or immediate, replaces the pending delete.

  • Scenario-3

    • Pending Action: Create

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending create.

  • Scenario-4

    • Pending Action: Create

    • New Request: Create

    • Result: The new create is added to the pending create.

      Important: If the new create request is Apply Immediately - Yes, all creates are performed immediately. If the new create request is Apply Immediately - No, all creates are pending.

Source

pub fn get_new_availability_zones(&self) -> &Option<Vec<String>>

This option is only supported on Memcached clusters.

The list of Availability Zones where the new Memcached cache nodes are created.

This parameter is only valid when NumCacheNodes in the request is greater than the sum of the number of active cache nodes and the number of cache nodes pending creation (which may be zero). The number of Availability Zones supplied in this list must match the cache nodes being added in this request.

Scenarios:

  • Scenario 1: You have 3 active nodes and wish to add 2 nodes. Specify NumCacheNodes=5 (3 + 2) and optionally specify two Availability Zones for the two new nodes.

  • Scenario 2: You have 3 active nodes and 2 nodes pending creation (from the scenario 1 call) and want to add 1 more node. Specify NumCacheNodes=6 ((3 + 2) + 1) and optionally specify an Availability Zone for the new node.

  • Scenario 3: You want to cancel all pending operations. Specify NumCacheNodes=3 to cancel all pending operations.

The Availability Zone placement of nodes pending creation cannot be modified. If you wish to cancel any nodes pending creation, add 0 nodes by setting NumCacheNodes to the number of current nodes.

If cross-az is specified, existing Memcached nodes remain in their current Availability Zone. Only newly created nodes can be located in different Availability Zones. For guidance on how to move existing Memcached nodes to different Availability Zones, see the Availability Zone Considerations section of Cache Node Considerations for Memcached.

Impact of new add/remove requests upon pending requests

  • Scenario-1

    • Pending Action: Delete

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending delete.

  • Scenario-2

    • Pending Action: Delete

    • New Request: Create

    • Result: The new create, pending or immediate, replaces the pending delete.

  • Scenario-3

    • Pending Action: Create

    • New Request: Delete

    • Result: The new delete, pending or immediate, replaces the pending create.

  • Scenario-4

    • Pending Action: Create

    • New Request: Create

    • Result: The new create is added to the pending create.

      Important: If the new create request is Apply Immediately - Yes, all creates are performed immediately. If the new create request is Apply Immediately - No, all creates are pending.

Source

pub fn cache_security_group_names(self, input: impl Into<String>) -> Self

Appends an item to cache_security_group_names.

To override the contents of this collection use set_cache_security_group_names.

A list of cache security group names to authorize on this cluster. This change is asynchronously applied as soon as possible.

You can use this parameter only with clusters that are created outside of an Amazon Virtual Private Cloud (Amazon VPC).

Constraints: Must contain no more than 255 alphanumeric characters. Must not be "Default".

Source

pub fn set_cache_security_group_names(self, input: Option<Vec<String>>) -> Self

A list of cache security group names to authorize on this cluster. This change is asynchronously applied as soon as possible.

You can use this parameter only with clusters that are created outside of an Amazon Virtual Private Cloud (Amazon VPC).

Constraints: Must contain no more than 255 alphanumeric characters. Must not be "Default".

Source

pub fn get_cache_security_group_names(&self) -> &Option<Vec<String>>

A list of cache security group names to authorize on this cluster. This change is asynchronously applied as soon as possible.

You can use this parameter only with clusters that are created outside of an Amazon Virtual Private Cloud (Amazon VPC).

Constraints: Must contain no more than 255 alphanumeric characters. Must not be "Default".

Source

pub fn security_group_ids(self, input: impl Into<String>) -> Self

Appends an item to security_group_ids.

To override the contents of this collection use set_security_group_ids.

Specifies the VPC Security Groups associated with the cluster.

This parameter can be used only with clusters that are created in an Amazon Virtual Private Cloud (Amazon VPC).

Source

pub fn set_security_group_ids(self, input: Option<Vec<String>>) -> Self

Specifies the VPC Security Groups associated with the cluster.

This parameter can be used only with clusters that are created in an Amazon Virtual Private Cloud (Amazon VPC).

Source

pub fn get_security_group_ids(&self) -> &Option<Vec<String>>

Specifies the VPC Security Groups associated with the cluster.

This parameter can be used only with clusters that are created in an Amazon Virtual Private Cloud (Amazon VPC).

Source

pub fn preferred_maintenance_window(self, input: impl Into<String>) -> Self

Specifies the weekly time range during which maintenance on the cluster is performed. It is specified as a range in the format ddd:hh24:mi-ddd:hh24:mi (24H Clock UTC). The minimum maintenance window is a 60 minute period.

Valid values for ddd are:

  • sun

  • mon

  • tue

  • wed

  • thu

  • fri

  • sat

Example: sun:23:00-mon:01:30

Source

pub fn set_preferred_maintenance_window(self, input: Option<String>) -> Self

Specifies the weekly time range during which maintenance on the cluster is performed. It is specified as a range in the format ddd:hh24:mi-ddd:hh24:mi (24H Clock UTC). The minimum maintenance window is a 60 minute period.

Valid values for ddd are:

  • sun

  • mon

  • tue

  • wed

  • thu

  • fri

  • sat

Example: sun:23:00-mon:01:30

Source

pub fn get_preferred_maintenance_window(&self) -> &Option<String>

Specifies the weekly time range during which maintenance on the cluster is performed. It is specified as a range in the format ddd:hh24:mi-ddd:hh24:mi (24H Clock UTC). The minimum maintenance window is a 60 minute period.

Valid values for ddd are:

  • sun

  • mon

  • tue

  • wed

  • thu

  • fri

  • sat

Example: sun:23:00-mon:01:30

Source

pub fn notification_topic_arn(self, input: impl Into<String>) -> Self

The Amazon Resource Name (ARN) of the Amazon SNS topic to which notifications are sent.

The Amazon SNS topic owner must be same as the cluster owner.

Source

pub fn set_notification_topic_arn(self, input: Option<String>) -> Self

The Amazon Resource Name (ARN) of the Amazon SNS topic to which notifications are sent.

The Amazon SNS topic owner must be same as the cluster owner.

Source

pub fn get_notification_topic_arn(&self) -> &Option<String>

The Amazon Resource Name (ARN) of the Amazon SNS topic to which notifications are sent.

The Amazon SNS topic owner must be same as the cluster owner.

Source

pub fn cache_parameter_group_name(self, input: impl Into<String>) -> Self

The name of the cache parameter group to apply to this cluster. This change is asynchronously applied as soon as possible for parameters when the ApplyImmediately parameter is specified as true for this request.

Source

pub fn set_cache_parameter_group_name(self, input: Option<String>) -> Self

The name of the cache parameter group to apply to this cluster. This change is asynchronously applied as soon as possible for parameters when the ApplyImmediately parameter is specified as true for this request.

Source

pub fn get_cache_parameter_group_name(&self) -> &Option<String>

The name of the cache parameter group to apply to this cluster. This change is asynchronously applied as soon as possible for parameters when the ApplyImmediately parameter is specified as true for this request.

Source

pub fn notification_topic_status(self, input: impl Into<String>) -> Self

The status of the Amazon SNS notification topic. Notifications are sent only if the status is active.

Valid values: active | inactive

Source

pub fn set_notification_topic_status(self, input: Option<String>) -> Self

The status of the Amazon SNS notification topic. Notifications are sent only if the status is active.

Valid values: active | inactive

Source

pub fn get_notification_topic_status(&self) -> &Option<String>

The status of the Amazon SNS notification topic. Notifications are sent only if the status is active.

Valid values: active | inactive

Source

pub fn apply_immediately(self, input: bool) -> Self

If true, this parameter causes the modifications in this request and any pending modifications to be applied, asynchronously and as soon as possible, regardless of the PreferredMaintenanceWindow setting for the cluster.

If false, changes to the cluster are applied on the next maintenance reboot, or the next failure reboot, whichever occurs first.

If you perform a ModifyCacheCluster before a pending modification is applied, the pending modification is replaced by the newer modification.

Valid values: true | false

Default: false

Source

pub fn set_apply_immediately(self, input: Option<bool>) -> Self

If true, this parameter causes the modifications in this request and any pending modifications to be applied, asynchronously and as soon as possible, regardless of the PreferredMaintenanceWindow setting for the cluster.

If false, changes to the cluster are applied on the next maintenance reboot, or the next failure reboot, whichever occurs first.

If you perform a ModifyCacheCluster before a pending modification is applied, the pending modification is replaced by the newer modification.

Valid values: true | false

Default: false

Source

pub fn get_apply_immediately(&self) -> &Option<bool>

If true, this parameter causes the modifications in this request and any pending modifications to be applied, asynchronously and as soon as possible, regardless of the PreferredMaintenanceWindow setting for the cluster.

If false, changes to the cluster are applied on the next maintenance reboot, or the next failure reboot, whichever occurs first.

If you perform a ModifyCacheCluster before a pending modification is applied, the pending modification is replaced by the newer modification.

Valid values: true | false

Default: false

Source

pub fn engine(self, input: impl Into<String>) -> Self

The engine type used by the cache cluster. The options are valkey, memcached or redis.

Source

pub fn set_engine(self, input: Option<String>) -> Self

The engine type used by the cache cluster. The options are valkey, memcached or redis.

Source

pub fn get_engine(&self) -> &Option<String>

The engine type used by the cache cluster. The options are valkey, memcached or redis.

Source

pub fn engine_version(self, input: impl Into<String>) -> Self

The upgraded version of the cache engine to be run on the cache nodes.

Important: You can upgrade to a newer engine version (see Selecting a Cache Engine and Version), but you cannot downgrade to an earlier engine version. If you want to use an earlier engine version, you must delete the existing cluster and create it anew with the earlier engine version.

Source

pub fn set_engine_version(self, input: Option<String>) -> Self

The upgraded version of the cache engine to be run on the cache nodes.

Important: You can upgrade to a newer engine version (see Selecting a Cache Engine and Version), but you cannot downgrade to an earlier engine version. If you want to use an earlier engine version, you must delete the existing cluster and create it anew with the earlier engine version.

Source

pub fn get_engine_version(&self) -> &Option<String>

The upgraded version of the cache engine to be run on the cache nodes.

Important: You can upgrade to a newer engine version (see Selecting a Cache Engine and Version), but you cannot downgrade to an earlier engine version. If you want to use an earlier engine version, you must delete the existing cluster and create it anew with the earlier engine version.

Source

pub fn auto_minor_version_upgrade(self, input: bool) -> Self

 If you are running Valkey 7.2 or Redis OSS engine version 6.0 or later, set this parameter to yes to opt-in to the next auto minor version upgrade campaign. This parameter is disabled for previous versions. 

Source

pub fn set_auto_minor_version_upgrade(self, input: Option<bool>) -> Self

 If you are running Valkey 7.2 or Redis OSS engine version 6.0 or later, set this parameter to yes to opt-in to the next auto minor version upgrade campaign. This parameter is disabled for previous versions. 

Source

pub fn get_auto_minor_version_upgrade(&self) -> &Option<bool>

 If you are running Valkey 7.2 or Redis OSS engine version 6.0 or later, set this parameter to yes to opt-in to the next auto minor version upgrade campaign. This parameter is disabled for previous versions. 

Source

pub fn snapshot_retention_limit(self, input: i32) -> Self

The number of days for which ElastiCache retains automatic cluster snapshots before deleting them. For example, if you set SnapshotRetentionLimit to 5, a snapshot that was taken today is retained for 5 days before being deleted.

If the value of SnapshotRetentionLimit is set to zero (0), backups are turned off.

Source

pub fn set_snapshot_retention_limit(self, input: Option<i32>) -> Self

The number of days for which ElastiCache retains automatic cluster snapshots before deleting them. For example, if you set SnapshotRetentionLimit to 5, a snapshot that was taken today is retained for 5 days before being deleted.

If the value of SnapshotRetentionLimit is set to zero (0), backups are turned off.

Source

pub fn get_snapshot_retention_limit(&self) -> &Option<i32>

The number of days for which ElastiCache retains automatic cluster snapshots before deleting them. For example, if you set SnapshotRetentionLimit to 5, a snapshot that was taken today is retained for 5 days before being deleted.

If the value of SnapshotRetentionLimit is set to zero (0), backups are turned off.

Source

pub fn snapshot_window(self, input: impl Into<String>) -> Self

The daily time range (in UTC) during which ElastiCache begins taking a daily snapshot of your cluster.

Source

pub fn set_snapshot_window(self, input: Option<String>) -> Self

The daily time range (in UTC) during which ElastiCache begins taking a daily snapshot of your cluster.

Source

pub fn get_snapshot_window(&self) -> &Option<String>

The daily time range (in UTC) during which ElastiCache begins taking a daily snapshot of your cluster.

Source

pub fn cache_node_type(self, input: impl Into<String>) -> Self

A valid cache node type that you want to scale this cluster up to.

Source

pub fn set_cache_node_type(self, input: Option<String>) -> Self

A valid cache node type that you want to scale this cluster up to.

Source

pub fn get_cache_node_type(&self) -> &Option<String>

A valid cache node type that you want to scale this cluster up to.

Source

pub fn auth_token(self, input: impl Into<String>) -> Self

Reserved parameter. The password used to access a password protected server. This parameter must be specified with the auth-token-update parameter. Password constraints:

  • Must be only printable ASCII characters

  • Must be at least 16 characters and no more than 128 characters in length

  • Cannot contain any of the following characters: '/', '"', or '@', '%'

For more information, see AUTH password at AUTH.

Source

pub fn set_auth_token(self, input: Option<String>) -> Self

Reserved parameter. The password used to access a password protected server. This parameter must be specified with the auth-token-update parameter. Password constraints:

  • Must be only printable ASCII characters

  • Must be at least 16 characters and no more than 128 characters in length

  • Cannot contain any of the following characters: '/', '"', or '@', '%'

For more information, see AUTH password at AUTH.

Source

pub fn get_auth_token(&self) -> &Option<String>

Reserved parameter. The password used to access a password protected server. This parameter must be specified with the auth-token-update parameter. Password constraints:

  • Must be only printable ASCII characters

  • Must be at least 16 characters and no more than 128 characters in length

  • Cannot contain any of the following characters: '/', '"', or '@', '%'

For more information, see AUTH password at AUTH.

Source

pub fn auth_token_update_strategy( self, input: AuthTokenUpdateStrategyType, ) -> Self

Specifies the strategy to use to update the AUTH token. This parameter must be specified with the auth-token parameter. Possible values:

  • ROTATE - default, if no update strategy is provided

  • SET - allowed only after ROTATE

  • DELETE - allowed only when transitioning to RBAC

For more information, see Authenticating Users with AUTH

Source

pub fn set_auth_token_update_strategy( self, input: Option<AuthTokenUpdateStrategyType>, ) -> Self

Specifies the strategy to use to update the AUTH token. This parameter must be specified with the auth-token parameter. Possible values:

  • ROTATE - default, if no update strategy is provided

  • SET - allowed only after ROTATE

  • DELETE - allowed only when transitioning to RBAC

For more information, see Authenticating Users with AUTH

Source

pub fn get_auth_token_update_strategy( &self, ) -> &Option<AuthTokenUpdateStrategyType>

Specifies the strategy to use to update the AUTH token. This parameter must be specified with the auth-token parameter. Possible values:

  • ROTATE - default, if no update strategy is provided

  • SET - allowed only after ROTATE

  • DELETE - allowed only when transitioning to RBAC

For more information, see Authenticating Users with AUTH

Source

pub fn log_delivery_configurations( self, input: LogDeliveryConfigurationRequest, ) -> Self

Appends an item to log_delivery_configurations.

To override the contents of this collection use set_log_delivery_configurations.

Specifies the destination, format and type of the logs.

Source

pub fn set_log_delivery_configurations( self, input: Option<Vec<LogDeliveryConfigurationRequest>>, ) -> Self

Specifies the destination, format and type of the logs.

Source

pub fn get_log_delivery_configurations( &self, ) -> &Option<Vec<LogDeliveryConfigurationRequest>>

Specifies the destination, format and type of the logs.

Source

pub fn ip_discovery(self, input: IpDiscovery) -> Self

The network type you choose when modifying a cluster, either ipv4 | ipv6. IPv6 is supported for workloads using Valkey 7.2 and above, Redis OSS engine version 6.2 to 7.1 or Memcached engine version 1.6.6 and above on all instances built on the Nitro system.

Source

pub fn set_ip_discovery(self, input: Option<IpDiscovery>) -> Self

The network type you choose when modifying a cluster, either ipv4 | ipv6. IPv6 is supported for workloads using Valkey 7.2 and above, Redis OSS engine version 6.2 to 7.1 or Memcached engine version 1.6.6 and above on all instances built on the Nitro system.

Source

pub fn get_ip_discovery(&self) -> &Option<IpDiscovery>

The network type you choose when modifying a cluster, either ipv4 | ipv6. IPv6 is supported for workloads using Valkey 7.2 and above, Redis OSS engine version 6.2 to 7.1 or Memcached engine version 1.6.6 and above on all instances built on the Nitro system.

Source

pub fn scale_config(self, input: ScaleConfig) -> Self

Configures horizontal or vertical scaling for Memcached clusters, specifying the scaling percentage and interval.

Source

pub fn set_scale_config(self, input: Option<ScaleConfig>) -> Self

Configures horizontal or vertical scaling for Memcached clusters, specifying the scaling percentage and interval.

Source

pub fn get_scale_config(&self) -> &Option<ScaleConfig>

Configures horizontal or vertical scaling for Memcached clusters, specifying the scaling percentage and interval.

Source

pub fn build(self) -> Result<ModifyCacheClusterInput, BuildError>

Consumes the builder and constructs a ModifyCacheClusterInput.

Source§

impl ModifyCacheClusterInputBuilder

Source

pub async fn send_with( self, client: &Client, ) -> Result<ModifyCacheClusterOutput, SdkError<ModifyCacheClusterError, HttpResponse>>

Sends a request with this input using the given client.

Trait Implementations§

Source§

impl Clone for ModifyCacheClusterInputBuilder

Source§

fn clone(&self) -> ModifyCacheClusterInputBuilder

Returns a duplicate of the value. Read more
1.0.0 · Source§

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source. Read more
Source§

impl Debug for ModifyCacheClusterInputBuilder

Source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more
Source§

impl Default for ModifyCacheClusterInputBuilder

Source§

fn default() -> ModifyCacheClusterInputBuilder

Returns the “default value” for a type. Read more
Source§

impl PartialEq for ModifyCacheClusterInputBuilder

Source§

fn eq(&self, other: &ModifyCacheClusterInputBuilder) -> bool

Tests for self and other values to be equal, and is used by ==.
1.0.0 · Source§

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.
Source§

impl StructuralPartialEq for ModifyCacheClusterInputBuilder

Auto Trait Implementations§

Blanket Implementations§

Source§

impl<T> Any for T
where T: 'static + ?Sized,

Source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
Source§

impl<T> Borrow<T> for T
where T: ?Sized,

Source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
Source§

impl<T> BorrowMut<T> for T
where T: ?Sized,

Source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
Source§

impl<T> CloneToUninit for T
where T: Clone,

Source§

unsafe fn clone_to_uninit(&self, dest: *mut u8)

🔬This is a nightly-only experimental API. (clone_to_uninit)
Performs copy-assignment from self to dest. Read more
Source§

impl<T> From<T> for T

Source§

fn from(t: T) -> T

Returns the argument unchanged.

Source§

impl<T> Instrument for T

Source§

fn instrument(self, span: Span) -> Instrumented<Self>

Instruments this type with the provided Span, returning an Instrumented wrapper. Read more
Source§

fn in_current_span(self) -> Instrumented<Self>

Instruments this type with the current Span, returning an Instrumented wrapper. Read more
Source§

impl<T, U> Into<U> for T
where U: From<T>,

Source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

Source§

impl<T> IntoEither for T

Source§

fn into_either(self, into_left: bool) -> Either<Self, Self>

Converts 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 more
Source§

fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
where F: FnOnce(&Self) -> bool,

Converts 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 more
Source§

impl<Unshared, Shared> IntoShared<Shared> for Unshared
where Shared: FromUnshared<Unshared>,

Source§

fn into_shared(self) -> Shared

Creates a shared type from an unshared type.
Source§

impl<T> Paint for T
where T: ?Sized,

Source§

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 primary(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Primary].

§Example
println!("{}", value.primary());
Source§

fn fixed(&self, color: u8) -> Painted<&T>

Returns self with the fg() set to [Color :: Fixed].

§Example
println!("{}", value.fixed(color));
Source§

fn rgb(&self, r: u8, g: u8, b: u8) -> Painted<&T>

Returns self with the fg() set to [Color :: Rgb].

§Example
println!("{}", value.rgb(r, g, b));
Source§

fn black(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Black].

§Example
println!("{}", value.black());
Source§

fn red(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Red].

§Example
println!("{}", value.red());
Source§

fn green(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Green].

§Example
println!("{}", value.green());
Source§

fn yellow(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Yellow].

§Example
println!("{}", value.yellow());
Source§

fn blue(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Blue].

§Example
println!("{}", value.blue());
Source§

fn magenta(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Magenta].

§Example
println!("{}", value.magenta());
Source§

fn cyan(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: Cyan].

§Example
println!("{}", value.cyan());
Source§

fn white(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: White].

§Example
println!("{}", value.white());
Source§

fn bright_black(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightBlack].

§Example
println!("{}", value.bright_black());
Source§

fn bright_red(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightRed].

§Example
println!("{}", value.bright_red());
Source§

fn bright_green(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightGreen].

§Example
println!("{}", value.bright_green());
Source§

fn bright_yellow(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightYellow].

§Example
println!("{}", value.bright_yellow());
Source§

fn bright_blue(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightBlue].

§Example
println!("{}", value.bright_blue());
Source§

fn bright_magenta(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightMagenta].

§Example
println!("{}", value.bright_magenta());
Source§

fn bright_cyan(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightCyan].

§Example
println!("{}", value.bright_cyan());
Source§

fn bright_white(&self) -> Painted<&T>

Returns self with the fg() set to [Color :: BrightWhite].

§Example
println!("{}", value.bright_white());
Source§

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>

Returns self with the bg() set to [Color :: Primary].

§Example
println!("{}", value.on_primary());
Source§

fn on_fixed(&self, color: u8) -> Painted<&T>

Returns self with the bg() set to [Color :: Fixed].

§Example
println!("{}", value.on_fixed(color));
Source§

fn on_rgb(&self, r: u8, g: u8, b: u8) -> Painted<&T>

Returns self with the bg() set to [Color :: Rgb].

§Example
println!("{}", value.on_rgb(r, g, b));
Source§

fn on_black(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Black].

§Example
println!("{}", value.on_black());
Source§

fn on_red(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Red].

§Example
println!("{}", value.on_red());
Source§

fn on_green(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Green].

§Example
println!("{}", value.on_green());
Source§

fn on_yellow(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Yellow].

§Example
println!("{}", value.on_yellow());
Source§

fn on_blue(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Blue].

§Example
println!("{}", value.on_blue());
Source§

fn on_magenta(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Magenta].

§Example
println!("{}", value.on_magenta());
Source§

fn on_cyan(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: Cyan].

§Example
println!("{}", value.on_cyan());
Source§

fn on_white(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: White].

§Example
println!("{}", value.on_white());
Source§

fn on_bright_black(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightBlack].

§Example
println!("{}", value.on_bright_black());
Source§

fn on_bright_red(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightRed].

§Example
println!("{}", value.on_bright_red());
Source§

fn on_bright_green(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightGreen].

§Example
println!("{}", value.on_bright_green());
Source§

fn on_bright_yellow(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightYellow].

§Example
println!("{}", value.on_bright_yellow());
Source§

fn on_bright_blue(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightBlue].

§Example
println!("{}", value.on_bright_blue());
Source§

fn on_bright_magenta(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightMagenta].

§Example
println!("{}", value.on_bright_magenta());
Source§

fn on_bright_cyan(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightCyan].

§Example
println!("{}", value.on_bright_cyan());
Source§

fn on_bright_white(&self) -> Painted<&T>

Returns self with the bg() set to [Color :: BrightWhite].

§Example
println!("{}", value.on_bright_white());
Source§

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 bold(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Bold].

§Example
println!("{}", value.bold());
Source§

fn dim(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Dim].

§Example
println!("{}", value.dim());
Source§

fn italic(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Italic].

§Example
println!("{}", value.italic());
Source§

fn underline(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Underline].

§Example
println!("{}", value.underline());

Returns self with the attr() set to [Attribute :: Blink].

§Example
println!("{}", value.blink());

Returns self with the attr() set to [Attribute :: RapidBlink].

§Example
println!("{}", value.rapid_blink());
Source§

fn invert(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Invert].

§Example
println!("{}", value.invert());
Source§

fn conceal(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Conceal].

§Example
println!("{}", value.conceal());
Source§

fn strike(&self) -> Painted<&T>

Returns self with the attr() set to [Attribute :: Strike].

§Example
println!("{}", value.strike());
Source§

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 mask(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: Mask].

§Example
println!("{}", value.mask());
Source§

fn wrap(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: Wrap].

§Example
println!("{}", value.wrap());
Source§

fn linger(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: Linger].

§Example
println!("{}", value.linger());
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.

Returns self with the quirk() set to [Quirk :: Clear].

§Example
println!("{}", value.clear());
Source§

fn resetting(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: Resetting].

§Example
println!("{}", value.resetting());
Source§

fn bright(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: Bright].

§Example
println!("{}", value.bright());
Source§

fn on_bright(&self) -> Painted<&T>

Returns self with the quirk() set to [Quirk :: OnBright].

§Example
println!("{}", value.on_bright());
Source§

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);
Source§

fn new(self) -> Painted<Self>
where Self: Sized,

Create a new Painted with a default Style. Read more
Source§

fn paint<S>(&self, style: S) -> Painted<&Self>
where S: Into<Style>,

Apply a style wholesale to self. Any previous style is replaced. Read more
Source§

impl<T> Same for T

Source§

type Output = T

Should always be Self
Source§

impl<T> ToOwned for T
where T: Clone,

Source§

type Owned = T

The resulting type after obtaining ownership.
Source§

fn to_owned(&self) -> T

Creates owned data from borrowed data, usually by cloning. Read more
Source§

fn clone_into(&self, target: &mut T)

Uses borrowed data to replace owned data, usually by cloning. Read more
Source§

impl<T, U> TryFrom<U> for T
where U: Into<T>,

Source§

type Error = Infallible

The type returned in the event of a conversion error.
Source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
Source§

impl<T, U> TryInto<U> for T
where U: TryFrom<T>,

Source§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
Source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.
Source§

impl<T> WithSubscriber for T

Source§

fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self>
where S: Into<Dispatch>,

Attaches the provided Subscriber to this type, returning a WithDispatch wrapper. Read more
Source§

fn with_current_subscriber(self) -> WithDispatch<Self>

Attaches the current default Subscriber to this type, returning a WithDispatch wrapper. Read more
Source§

impl<T> ErasedDestructor for T
where T: 'static,