The ID of the tenant. A tenant is also known as an account or project.

A name for the new stack.

This value must be unique within a project. The name must start with an ASCII letter and can contain ASCII letters, digits, underscores, periods, and hyphens. Specifically, the name must match the ^[a-zA-Z][a-zA-Z0-9_.-]*$ regular expression.

When you delete or abandon a stack, its name might not be available for reuse for an unspecified period of time.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

Supplies the contents of files referenced in the template or the environment. Stack templates and resource templates can explicitly reference files by using the get_file intrinsic function. In addition, the environment parameter can contain implicit references to files.

The value is a JSON object, where each key is a relative or absolute URI which serves as the name of a file, and the associated value provides the contents of the file. The following code shows the general structure of this parameter.

{ ...
    "files": {
        "fileA.yaml": "Contents of the file",
        "file:///usr/fileB.template": "Contents of the file",
        "http://example.com/fileC.template": "Contents of the file"
    }
... 
}

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

Do not use this parameter to provide the content of the template located at the address specified by template_url. Instead, use the template parameter to supply the template content as part of the request.

Supplies arguments for parameters defined in the stack template.

The value is a JSON object, where each key is the name of a parameter defined in the template and the associated value is the argument to use for that parameter when instantiating the template. The following code shows the general structure of this parameter. In the example, a and b would be the names of two parameters defined in the template.

{ ...
    "parameters": {
        "a": "Value",
        "b": "3"
    }
... 
}

While the service accepts JSON numbers for parameters with the type number and JSON objects for parameters with the type json, all parameter values are converted to their string representation for storage in the created Stack. Clients are encouraged to send all parameter values using their string representation for consistency between requests and responses from the Orchestration service.

A value must be provided for each template parameter which does not specify a default value. However, this parameter is not allowed to contain JSON properties with names that do not match a parameter defined in the template.

The files parameter maps logical file names to file contents. Both the get_file intrinsic function and provider template functionality use this mapping. When you want to use a provider template, for example, the Orchestration service adds an entry to the files map by using:

• The URL of the provider template as the name.

• The contents of that file as the value.

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

One or more simple string tags to associate with the stack. To associate multiple tags with a stack, separate the tags with commas. For example, tag1,tag2.

The name of the stack to create.

The URL of the template.

A JSON template.

A JSON environment for the stack.

A map of file names to JSON template bodies. File names are provider resource templates, as referenced in the environment.

User-defined parameter names to pass to the template.

User-defined parameter values to pass to the template.

The timeout for stack creation in minutes.

Enables or disables deletion of all previously-created stack resources when stack creation fails. Set to True to keep all previously-created stack resources when stack creation fails. Set to False to delete all previously-created stack resources when stack creation fails. Default is True.

The system-assigned ID for the stack.

A list of URLs for the stack.

A reference to the stack's parent. If no parent, reference is self.

The ID of the tenant. A tenant is also known as an account or project.

A name for the new stack.

The value must be unique within a project. The name must start with an ASCII letter and can contain ASCII letters, digits, underscores, periods, and hyphens. Specifically, the name must match the ^[a-zA-Z][a-zA-Z0-9_.-]*$ regular expression.

When you delete or abandon a stack, its name might not be available for reuse for an unspecified period of time.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

A JSON environment for the stack.

Supplies the contents of files referenced in the template or the environment. Stack templates and resource templates can explicitly reference files by using the get_file intrinsic function. In addition, the environment parameter can contain implicit references to files.

The value is a JSON object, where each key is a relative or absolute URI which serves as the name of a file, and the associated value provides the contents of the file. The following code shows the general structure of this parameter.

{ ...
    "files": {
        "fileA.yaml": "Contents of the file",
        "file:///usr/fileB.template": "Contents of the file",
        "http://example.com/fileC.template": "Contents of the file"
    }
... 
}

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

Do not use this parameter to provide the content of the template located at the address specified by template_url. Instead, use the template parameter to supply the template content as part of the request.

Supplies arguments for parameters defined in the stack template.

The value is a JSON object, where each key is the name of a parameter defined in the template and the associated value is the argument to use for that parameter when instantiating the template. The following code shows the general structure of this parameter. In the example, a and b would be the names of two parameters defined in the template.

{ ...
    "parameters": {
        "a": "Value",
        "b": "3"
    }
... 
}

While the service accepts JSON numbers for parameters with the type number and JSON objects for parameters with the type json, all parameter values are converted to their string representation for storage in the created Stack. Clients are encouraged to send all parameter values using their string representation for consistency between requests and responses from the Orchestration service.

A value must be provided for each template parameter which does not specify a default value. However, this parameter is not allowed to contain JSON properties with names that do not match a parameter defined in the template.

The files parameter maps logical file names to file contents. Both the get_file intrinsic function and provider template functionality use this mapping. When you want to use a provider template, for example, the Orchestration service adds an entry to the files map by using:

• The URL of the provider template as the name.

• The contents of that file as the value.

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

The timeout for stack creation in minutes.

Existing resources data to adopt a stack. Data returned by abandon stack could be provided as adopt_stack_data.

Enables or disables deletion of all stack resources when stack creation fails. Set to True to keep all resources when stack creation fails. Set to False to delete all resources when stack creation fails. Default is True.

The ID of the tenant. A tenant is also known as an account or project.

Filters the stack list by a specified stack ID. Use this filter multiple times to filter by multiple IDs.

Filters the stack list by a specified status. Use this filter multiple times to filter by multiple statuses.

Filters the stack list by a specified name. Use this filter multiple times to filter by multiple names.

Filters the stack list by a specified action. Use this filter multiple times to filter by multiple actions.

Filters the stack list by a specified tenant. Use this filter multiple times to filter by multiple tenants.

Filters the stack list by a specified user name. Use this filter multiple times to filter by multiple user names.

Filters the stack list by a specified owner ID, which is the ID of the parent stack of listed stack. Use this filter multiple times to filter by multiple owner IDs.

Requests a specified page size of returned items from the query. Returns a number of items up to the specified limit value. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Specifies the ID of the last-seen item. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Specifies whether to include deleted stacks in the list. Default is False, which excludes deleted stacks from the list.

Specifies whether to include nested stacks in the list. Default is False, which excludes nested stacks from the list.

Sorts the stack list by name, status, created_at, or updated_at key.

Lists stacks that contain one or more simple string tags. To specify multiple tags, separate the tags with commas. For example, tag1,tag2. The boolean AND expression is used to combine multiple tags.

Lists stacks that contain one or more simple string tags. To specify multiple tags, separate the tags with commas. For example, tag1,tag2. The boolean OR expression is used to combine multiple tags.

Lists stacks that do not contain one or more simple string tags. To specify multiple tags, separate the tags with commas. For example, tag1,tag2. The boolean AND expression is used to combine multiple tags.

Lists stacks that do not contain one or more simple string tags. To specify multiple tags, separate the tags with commas. For example, tag1,tag2. The boolean OR expression is used to combine multiple tags.

The sort direction of the list. A valid value is asc (ascending) or desc (descending).

Specifies whether to include stacks from all tenants in the stack list. Policy requirements are specified in the Orchestration policy.json file. Default is False.

Specifies whether to include a count key in the response. The count key value is the number of stacks that match the query criteria. Default is False.

The ID of the tenant. A tenant is also known as an account or project.

A name for the new stack.

The value must be unique within a project. The name must start with an ASCII letter and can contain ASCII letters, digits, underscores, periods, and hyphens. Specifically, the name must match the ^[a-zA-Z][a-zA-Z0-9_.-]*$ regular expression.

When you delete or abandon a stack, its name might not be available for reuse for an unspecified period of time.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

Supplies the contents of files referenced in the template or the environment. Stack templates and resource templates can explicitly reference files by using the get_file intrinsic function. In addition, the environment parameter can contain implicit references to files.

The value is a JSON object, where each key is a relative or absolute URI which serves as the name of a file, and the associated value provides the contents of the file. The following code shows the general structure of this parameter.

{ ...
    "files": {
        "fileA.yaml": "Contents of the file",
        "file:///usr/fileB.template": "Contents of the file",
        "http://example.com/fileC.template": "Contents of the file"
    }
... 
}

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

Do not use this parameter to provide the content of the template located at the address specified by template_url. Instead, use the template parameter to supply the template content as part of the request.

Supplies arguments for parameters defined in the stack template.

The value is a JSON object, where each key is the name of a parameter defined in the template and the associated value is the argument to use for that parameter when instantiating the template. The following code shows the general structure of this parameter. In the example, a and b would be the names of two parameters defined in the template.

{ ...
    "parameters": {
        "a": "Value",
        "b": "3"
    }
... 
}

While the service accepts JSON numbers for parameters with the type number and JSON objects for parameters with the type json, all parameter values are converted to their string representation for storage in the created Stack. Clients are encouraged to send all parameter values using their string representation for consistency between requests and responses from the Orchestration service.

A value must be provided for each template parameter which does not specify a default value. However, this parameter is not allowed to contain JSON properties with names that do not match a parameter defined in the template.

The files parameter maps logical file names to file contents. Both the get_file intrinsic function and provider template functionality use this mapping. When you want to use a provider template, for example, the Orchestration service adds an entry to the files map by using:

• The URL of the provider template as the name.

• The contents of that file as the value.

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

The stack ID of the parent stack, if this is a nested stack.

The stack ID.

The name of the stack.

A description of the stack.

A description of the template that defines the stack.

Time-lines for stack creation.

Enables or disables stack rollback when stack creation fails. Set to True to rollback the stack when stack creation fails. Set to False to disable stack rollback when stack creation fails. Default is True.

List of stack capabilities for stack.

List of notification topics for stack.

Time of last stack update in the following format: YYYY-MM-DDThh:mm:ssTZD, where TZD is the time zone designator.

Stack owner name.

List of parameters defined for the stack.

List of stack resources.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

A JSON environment for the stack.

Supplies the contents of files referenced in the template or the environment. Stack templates and resource templates can explicitly reference files by using the get_file intrinsic function. In addition, the environment parameter can contain implicit references to files.

The value is a JSON object, where each key is a relative or absolute URI which serves as the name of a file, and the associated value provides the contents of the file. The following code shows the general structure of this parameter.

{ ...
    "files": {
        "fileA.yaml": "Contents of the file",
        "file:///usr/fileB.template": "Contents of the file",
        "http://example.com/fileC.template": "Contents of the file"
    }
... 
}

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

Do not use this parameter to provide the content of the template located at the address specified by template_url. Instead, use the template parameter to supply the template content as part of the request.

One or more simple string tags to associate with the stack. To associate multiple tags with a stack, separate the tags with commas. For example, tag1,tag2.

This parameter supplies updated arguments for parameters defined in the stack template.

The value is a JSON object, where each key is the name of a parameter defined in the template and the associated value is the argument to use for that parameter when instantiating the template. The following code shows the general structure of this parameter. In the example, a and b are the names of two parameters defined in the template.

{ ...
                      "parameters": {
                      "a": "Value",
                      "b": "3"
                      }
                      ... }
                   

While the service accepts JSON numbers for parameters with the type number and JSON objects for parameters with the type json, all parameter values are converted to their string representation for storage in the created Stack. Clients are encouraged to send all parameter values using their string representation for consistency between requests and responses from the Orchestration service.

You must specify a value for each template parameter that does not have a default value. However, this parameter cannot contain JSON properties with names that do not match a parameter that is defined in the template.

The timeout for stack creation in minutes.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

A JSON environment for the stack.

Supplies the contents of files referenced in the template or the environment. Stack templates and resource templates can explicitly reference files by using the get_file intrinsic function. In addition, the environment parameter can contain implicit references to files.

The value is a JSON object, where each key is a relative or absolute URI which serves as the name of a file, and the associated value provides the contents of the file. The following code shows the general structure of this parameter.

{ ...
    "files": {
        "fileA.yaml": "Contents of the file",
        "file:///usr/fileB.template": "Contents of the file",
        "http://example.com/fileC.template": "Contents of the file"
    }
... 
}

Additionally, some template authors encode their user data in a local file. The Orchestration client examines the template for the get_file intrinsic function and adds an entry to the files map with the path to the file as the name and the file contents as the value. So, a simple example looks like this:

{
   "files": {
      "myfile": "#!/bin/bash\necho \"Hello world\" > /root/testfile.txt"
   },
   ...,
   "stack_name": "teststack",
   "template": {
      ...,
      "resources": {
         "my_server": {
            "type": "OS::Nova::Server",
            "properties": {
               ...,
               "user_data": {
                  "get_file": "myfile"
               }
            }
         }
      }
   },
   "timeout_mins": 60
}

Do not use this parameter to provide the content of the template located at the address specified by template_url. Instead, use the template parameter to supply the template content as part of the request.

One or more simple string tags to associate with the stack. To associate multiple tags with a stack, separate the tags with commas. For example, tag1,tag2.

This parameter supplies updated arguments for parameters defined in the stack template.

The value is a JSON object, where each key is the name of a parameter defined in the template and the associated value is the argument to use for that parameter when instantiating the template. The following code shows the general structure of this parameter. In the example, a and b are the names of two parameters defined in the template.

{ ...
                     "parameters": {
                     "a": "Value",
                     "b": "3"
                     }
                     ... }
                  

While the service accepts JSON numbers for parameters with the type number and JSON objects for parameters with the type json, all parameter values are converted to their string representation for storage in the created Stack. Clients are encouraged to send all parameter values using their string representation for consistency between requests and responses from the Orchestration service.

You must specify a value for each template parameter that does not have a default value. However, this parameter cannot contain JSON properties with names that do not match a parameter that is defined in the template.

The timeout for stack creation in minutes.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of the snapshot.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The snapshot ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The snapshot ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The snapshot ID.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Specify the suspend action in the request body.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Specify the resume action in the request body.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Specify the cancel_update action in the request body.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Specify the check action in the request body.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Includes resources from nested stacks up to the nested_depth levels of recursion.

Enables detailed resource information for each resource in list of resources.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of a resource in the stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of a resource in the stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of a resource in the stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

Filters the event list by a specified resource action. You can use this filter multiple times to filter by multiple resource actions. Valid resource actions are ADOPT, CHECK, CREATE, DELETE, INIT, RESTORE, RESUME, ROLLBACK, SNAPSHOT, SUSPEND, and UPDATE.

Filters the event list by a specified resource status. You can use this filter multiple times to filter by multiple resource statuses. Valid resource statuses are COMPLETE, FAILED, and IN_PROGRESS.

Filters the event list by a specified resource name. You can use this filter multiple times to filter by multiple resource names.

Filters the event list by a specified resource type. You can use this filter multiple times to filter by multiple resource types. Valid resource types include OS::Cinder::Volume, OS::Nova::Server, OS::Neutron::Port, and so on.

Requests a specified page size of returned items from the query. Returns a number of items up to the specified limit value. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Specifies the ID of the last-seen item. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Sorts the list by the resource_type or created_at key.

The sort direction of the list. A valid value is asc (ascending) or desc (descending).

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of a resource in the stack.

Filters the event list by a specified resource action. You can use this filter multiple times to filter by multiple resource actions. Valid resource actions are ADOPT, CHECK, CREATE, DELETE, INIT, RESTORE, RESUME, ROLLBACK, SNAPSHOT, SUSPEND, and UPDATE.

Filters the event list by a specified resource status. You can use this filter multiple times to filter by multiple resource statuses. Valid resource statuses are COMPLETE, FAILED, and IN_PROGRESS.

Filters the event list by a specified resource name. You can use this filter multiple times to filter by multiple resource names.

Filters the event list by a specified resource type. You can use this filter multiple times to filter by multiple resource types. Valid resource types include OS::Cinder::Volume, OS::Nova::Server, OS::Neutron::Port, and so on.

Requests a specified page size of returned items from the query. Returns a number of items up to the specified limit value. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Specifies the ID of the last-seen item. Use the limit parameter to make an initial limited request and use the ID of the last-seen item from the response as the marker parameter value in a subsequent limited request.

Sorts the list by the resource_type or created_at key.

The sort direction of the list. A valid value is asc (ascending) or desc (descending).

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The name of a resource in the stack.

The ID of an event related to the resource in the stack.

The ID of the tenant. A tenant is also known as an account or project.

The name of a stack.

The stack ID.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the tenant. A tenant is also known as an account or project.

A URI to the location containing the stack template on which to perform the specified operation.

See the description of the template parameter for information about the expected template content located at the URI.

This parameter is only required when you omit the template parameter. If you specify both parameters, this parameter is ignored.

The stack template on which to perform the specified operation.

This parameter is always provided as a string in the JSON request body. The content of the string is a JSON- or YAML-formatted Orchestration template. For example:

"template": {
    "heat_template_version": "2013-05-23",
    ...}

This parameter is required only when you omit the template_url parameter. If you specify both parameters, this value overrides the template_url parameter value.

A JSON environment for the stack.

The description specified in the template.

An object that defines all input parameters that are defined in the template. Indexed by parameter name.

A list of parameter groups. Each group contains a list of parameter names.

The ID of the tenant. A tenant is also known as an account or project.

The name of a resource type.

The resource template type. Default type is cfn. The hot template type is supported.

The ID of the tenant. A tenant is also known as an account or project.

The name of a resource type.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the tenant. A tenant is also known as an account or project.

Configuration script or manifest that defines which configuration is performed.

Namespace that groups this software configuration by when it is delivered to a server. This setting might simply define which configuration tool performs the configuration.

The name of the configuration to create.

Schema that represents the inputs that this software configuration expects.

Schema that represents the outputs that this software configuration produces.

Map that contains options that are specific to the configuration management tool that this resource uses.

The ID of the tenant. A tenant is also known as an account or project.

The configuration ID.

The ID of the tenant. A tenant is also known as an account or project.

The configuration ID.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the software configuration resource that runs when applying to the server.

The ID of the compute server to which the configuration applies.

The current stack action that triggers this deployment resource.

Authentication project ID, which can also perform operations on this deployment.

Current status of the deployment. A valid value is COMPLETE, IN_PROGRESS, or FAILED.

Error description for the last status change, which is FAILED status.

The ID of the tenant. A tenant is also known as an account or project.

The ID of the server for which to fetch configuration metadata.

The ID of the tenant. A tenant is also known as an account or project.

The deployment ID.

The ID of the tenant. A tenant is also known as an account or project.

The deployment ID.

ID of the software configuration resource to run when applying to the server. This ID might not be the same configuration ID with which the deployment was created because ephemeral configurations are created throughout the life cycle of the deployment.

Current stack action in which this deployment resource is being triggered.

Current status of the deployment. Value is IN_PROGRESS, COMPLETE, or FAILED.

Error description for the last status change, which is FAILED status.

Map of output values for the deployment, as signaled from the server.

The ID of the tenant. A tenant is also known as an account or project.

The deployment ID.

The ID of the tenant. A tenant is also known as an account or project.