1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146

// Code generated by software.amazon.smithy.rust.codegen.smithy-rs. DO NOT EDIT.

/// <p>Structure containing the rollback triggers for CloudFormation to monitor during stack creation and updating operations, and for the specified monitoring period afterwards.</p>
/// <p>Rollback triggers enable you to have CloudFormation monitor the state of your application during stack creation and updating, and to roll back that operation if the application breaches the threshold of any of the alarms you've specified. For more information, see <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html">Monitor and Roll Back Stack Operations</a>.</p>
#[non_exhaustive]
#[derive(::std::clone::Clone, ::std::cmp::PartialEq, ::std::fmt::Debug)]
pub struct RollbackConfiguration {
    /// <p>The triggers to monitor during stack creation or update actions.</p>
    /// <p>By default, CloudFormation saves the rollback triggers specified for a stack and applies them to any subsequent update operations for the stack, unless you specify otherwise. If you do specify rollback triggers for this parameter, those triggers replace any list of triggers previously specified for the stack. This means:</p>
    /// <ul>
    /// <li>
    /// <p>To use the rollback triggers previously specified for this stack, if any, don't specify this parameter.</p></li>
    /// <li>
    /// <p>To specify new or updated rollback triggers, you must specify <i>all</i> the triggers that you want used for this stack, even triggers you've specified before (for example, when creating the stack or during a previous stack update). Any triggers that you don't include in the updated list of triggers are no longer applied to the stack.</p></li>
    /// <li>
    /// <p>To remove all currently specified triggers, specify an empty list for this parameter.</p></li>
    /// </ul>
    /// <p>If a specified trigger is missing, the entire stack operation fails and is rolled back.</p>
    pub rollback_triggers: ::std::option::Option<::std::vec::Vec<crate::types::RollbackTrigger>>,
    /// <p>The amount of time, in minutes, during which CloudFormation should monitor all the rollback triggers after the stack creation or update operation deploys all necessary resources.</p>
    /// <p>The default is 0 minutes.</p>
    /// <p>If you specify a monitoring period but don't specify any rollback triggers, CloudFormation still waits the specified period of time before cleaning up old resources after update operations. You can use this monitoring period to perform any manual stack validation desired, and manually cancel the stack creation or update (using <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CancelUpdateStack.html">CancelUpdateStack</a>, for example) as necessary.</p>
    /// <p>If you specify 0 for this parameter, CloudFormation still monitors the specified rollback triggers during stack creation and update operations. Then, for update operations, it begins disposing of old resources immediately once the operation completes.</p>
    pub monitoring_time_in_minutes: ::std::option::Option<i32>,
}
impl RollbackConfiguration {
    /// <p>The triggers to monitor during stack creation or update actions.</p>
    /// <p>By default, CloudFormation saves the rollback triggers specified for a stack and applies them to any subsequent update operations for the stack, unless you specify otherwise. If you do specify rollback triggers for this parameter, those triggers replace any list of triggers previously specified for the stack. This means:</p>
    /// <ul>
    /// <li>
    /// <p>To use the rollback triggers previously specified for this stack, if any, don't specify this parameter.</p></li>
    /// <li>
    /// <p>To specify new or updated rollback triggers, you must specify <i>all</i> the triggers that you want used for this stack, even triggers you've specified before (for example, when creating the stack or during a previous stack update). Any triggers that you don't include in the updated list of triggers are no longer applied to the stack.</p></li>
    /// <li>
    /// <p>To remove all currently specified triggers, specify an empty list for this parameter.</p></li>
    /// </ul>
    /// <p>If a specified trigger is missing, the entire stack operation fails and is rolled back.</p>
    ///
    /// If no value was sent for this field, a default will be set. If you want to determine if no value was sent, use `.rollback_triggers.is_none()`.
    pub fn rollback_triggers(&self) -> &[crate::types::RollbackTrigger] {
        self.rollback_triggers.as_deref().unwrap_or_default()
    }
    /// <p>The amount of time, in minutes, during which CloudFormation should monitor all the rollback triggers after the stack creation or update operation deploys all necessary resources.</p>
    /// <p>The default is 0 minutes.</p>
    /// <p>If you specify a monitoring period but don't specify any rollback triggers, CloudFormation still waits the specified period of time before cleaning up old resources after update operations. You can use this monitoring period to perform any manual stack validation desired, and manually cancel the stack creation or update (using <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CancelUpdateStack.html">CancelUpdateStack</a>, for example) as necessary.</p>
    /// <p>If you specify 0 for this parameter, CloudFormation still monitors the specified rollback triggers during stack creation and update operations. Then, for update operations, it begins disposing of old resources immediately once the operation completes.</p>
    pub fn monitoring_time_in_minutes(&self) -> ::std::option::Option<i32> {
        self.monitoring_time_in_minutes
    }
}
impl RollbackConfiguration {
    /// Creates a new builder-style object to manufacture [`RollbackConfiguration`](crate::types::RollbackConfiguration).
    pub fn builder() -> crate::types::builders::RollbackConfigurationBuilder {
        crate::types::builders::RollbackConfigurationBuilder::default()
    }
}

/// A builder for [`RollbackConfiguration`](crate::types::RollbackConfiguration).
#[non_exhaustive]
#[derive(::std::clone::Clone, ::std::cmp::PartialEq, ::std::default::Default, ::std::fmt::Debug)]
pub struct RollbackConfigurationBuilder {
    pub(crate) rollback_triggers: ::std::option::Option<::std::vec::Vec<crate::types::RollbackTrigger>>,
    pub(crate) monitoring_time_in_minutes: ::std::option::Option<i32>,
}
impl RollbackConfigurationBuilder {
    /// Appends an item to `rollback_triggers`.
    ///
    /// To override the contents of this collection use [`set_rollback_triggers`](Self::set_rollback_triggers).
    ///
    /// <p>The triggers to monitor during stack creation or update actions.</p>
    /// <p>By default, CloudFormation saves the rollback triggers specified for a stack and applies them to any subsequent update operations for the stack, unless you specify otherwise. If you do specify rollback triggers for this parameter, those triggers replace any list of triggers previously specified for the stack. This means:</p>
    /// <ul>
    /// <li>
    /// <p>To use the rollback triggers previously specified for this stack, if any, don't specify this parameter.</p></li>
    /// <li>
    /// <p>To specify new or updated rollback triggers, you must specify <i>all</i> the triggers that you want used for this stack, even triggers you've specified before (for example, when creating the stack or during a previous stack update). Any triggers that you don't include in the updated list of triggers are no longer applied to the stack.</p></li>
    /// <li>
    /// <p>To remove all currently specified triggers, specify an empty list for this parameter.</p></li>
    /// </ul>
    /// <p>If a specified trigger is missing, the entire stack operation fails and is rolled back.</p>
    pub fn rollback_triggers(mut self, input: crate::types::RollbackTrigger) -> Self {
        let mut v = self.rollback_triggers.unwrap_or_default();
        v.push(input);
        self.rollback_triggers = ::std::option::Option::Some(v);
        self
    }
    /// <p>The triggers to monitor during stack creation or update actions.</p>
    /// <p>By default, CloudFormation saves the rollback triggers specified for a stack and applies them to any subsequent update operations for the stack, unless you specify otherwise. If you do specify rollback triggers for this parameter, those triggers replace any list of triggers previously specified for the stack. This means:</p>
    /// <ul>
    /// <li>
    /// <p>To use the rollback triggers previously specified for this stack, if any, don't specify this parameter.</p></li>
    /// <li>
    /// <p>To specify new or updated rollback triggers, you must specify <i>all</i> the triggers that you want used for this stack, even triggers you've specified before (for example, when creating the stack or during a previous stack update). Any triggers that you don't include in the updated list of triggers are no longer applied to the stack.</p></li>
    /// <li>
    /// <p>To remove all currently specified triggers, specify an empty list for this parameter.</p></li>
    /// </ul>
    /// <p>If a specified trigger is missing, the entire stack operation fails and is rolled back.</p>
    pub fn set_rollback_triggers(mut self, input: ::std::option::Option<::std::vec::Vec<crate::types::RollbackTrigger>>) -> Self {
        self.rollback_triggers = input;
        self
    }
    /// <p>The triggers to monitor during stack creation or update actions.</p>
    /// <p>By default, CloudFormation saves the rollback triggers specified for a stack and applies them to any subsequent update operations for the stack, unless you specify otherwise. If you do specify rollback triggers for this parameter, those triggers replace any list of triggers previously specified for the stack. This means:</p>
    /// <ul>
    /// <li>
    /// <p>To use the rollback triggers previously specified for this stack, if any, don't specify this parameter.</p></li>
    /// <li>
    /// <p>To specify new or updated rollback triggers, you must specify <i>all</i> the triggers that you want used for this stack, even triggers you've specified before (for example, when creating the stack or during a previous stack update). Any triggers that you don't include in the updated list of triggers are no longer applied to the stack.</p></li>
    /// <li>
    /// <p>To remove all currently specified triggers, specify an empty list for this parameter.</p></li>
    /// </ul>
    /// <p>If a specified trigger is missing, the entire stack operation fails and is rolled back.</p>
    pub fn get_rollback_triggers(&self) -> &::std::option::Option<::std::vec::Vec<crate::types::RollbackTrigger>> {
        &self.rollback_triggers
    }
    /// <p>The amount of time, in minutes, during which CloudFormation should monitor all the rollback triggers after the stack creation or update operation deploys all necessary resources.</p>
    /// <p>The default is 0 minutes.</p>
    /// <p>If you specify a monitoring period but don't specify any rollback triggers, CloudFormation still waits the specified period of time before cleaning up old resources after update operations. You can use this monitoring period to perform any manual stack validation desired, and manually cancel the stack creation or update (using <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CancelUpdateStack.html">CancelUpdateStack</a>, for example) as necessary.</p>
    /// <p>If you specify 0 for this parameter, CloudFormation still monitors the specified rollback triggers during stack creation and update operations. Then, for update operations, it begins disposing of old resources immediately once the operation completes.</p>
    pub fn monitoring_time_in_minutes(mut self, input: i32) -> Self {
        self.monitoring_time_in_minutes = ::std::option::Option::Some(input);
        self
    }
    /// <p>The amount of time, in minutes, during which CloudFormation should monitor all the rollback triggers after the stack creation or update operation deploys all necessary resources.</p>
    /// <p>The default is 0 minutes.</p>
    /// <p>If you specify a monitoring period but don't specify any rollback triggers, CloudFormation still waits the specified period of time before cleaning up old resources after update operations. You can use this monitoring period to perform any manual stack validation desired, and manually cancel the stack creation or update (using <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CancelUpdateStack.html">CancelUpdateStack</a>, for example) as necessary.</p>
    /// <p>If you specify 0 for this parameter, CloudFormation still monitors the specified rollback triggers during stack creation and update operations. Then, for update operations, it begins disposing of old resources immediately once the operation completes.</p>
    pub fn set_monitoring_time_in_minutes(mut self, input: ::std::option::Option<i32>) -> Self {
        self.monitoring_time_in_minutes = input;
        self
    }
    /// <p>The amount of time, in minutes, during which CloudFormation should monitor all the rollback triggers after the stack creation or update operation deploys all necessary resources.</p>
    /// <p>The default is 0 minutes.</p>
    /// <p>If you specify a monitoring period but don't specify any rollback triggers, CloudFormation still waits the specified period of time before cleaning up old resources after update operations. You can use this monitoring period to perform any manual stack validation desired, and manually cancel the stack creation or update (using <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CancelUpdateStack.html">CancelUpdateStack</a>, for example) as necessary.</p>
    /// <p>If you specify 0 for this parameter, CloudFormation still monitors the specified rollback triggers during stack creation and update operations. Then, for update operations, it begins disposing of old resources immediately once the operation completes.</p>
    pub fn get_monitoring_time_in_minutes(&self) -> &::std::option::Option<i32> {
        &self.monitoring_time_in_minutes
    }
    /// Consumes the builder and constructs a [`RollbackConfiguration`](crate::types::RollbackConfiguration).
    pub fn build(self) -> crate::types::RollbackConfiguration {
        crate::types::RollbackConfiguration {
            rollback_triggers: self.rollback_triggers,
            monitoring_time_in_minutes: self.monitoring_time_in_minutes,
        }
    }
}