When creating stacks, the OpenStack Orchestration service (Heat) reuses the incoming token of a user to create resources under the user’s project ownership and to honor RBAC restrictions applicable to this user.
This logic has certain consequences when the stacks creation takes longer than the token expiration time set in the OpenStack Identity service (Keystone) configuration. Therefore, you should plan the expected type of the Heat stacks users to be created in your MCP cluster. Consider the following common issues and ways to overcome them:
Heat fails to create a stack resource
When creating resources from a template, Heat internally builds a graph for
resources to be created, updated, or deleted in a well-defined order.
If at some point an operation on intermediate resources takes longer than
the Keystone token expiration time, the user token that Heat keeps
expires and Heat can no longer use it to access other OpenStack APIs.
This manifests as 401 Unauthorized error when trying to modify
(create, update, or delete) a resource in another OpenStack service.
If you anticipate that your users will create such stacks, consider enabling the following option in the Heat configuration file:
[DEFAULT]
reauthentication_auth_method = trusts
With this setting, Heat creates a Keystone trust between the user set
in the [trustee] section of the Heat configuration file
and the user who made the request to Heat.
With this trust available, Heat can impersonate the user
in all communications with other OpenStack APIs and
get a new Keystone token when the initial one expires.
Warning
This setting effectively circumvents the token expiry.
Note
Alternatively, a cloud operator can increase the token lifetime to be longer than the maximum anticipated Heat stack creation time.
Since the MCP 2019.2.4 maintenance update, you can set the Keystone trust in your Reclass cluster model:
heat:
server:
reauthentication_auth_method: trusts
Signaling to the Heat WaitCondition with curl is failing
A common use case when provisioning the Nova instances using
the Heat templates is to utilize the OS::Heat::WaitCondition and
OS::Heat::WaitConditionHandle resources to signal Heat that
the initial configuration of the instance with the user data script is done.
This is commonly done using the value of the curl_cli attribute of the
OS::WaitConditionHandle resource inside the user data to be passed
to Nova when creating the instance.
The value of this attribute contains a predefined command that uses
the curl tool to make a request to the Heat API
including the appropriate address and the Keystone token.
However, the token to use with this request is generated
when the corresponding OS::Heat::WaitConditionHandle resource goes
to CREATE_COMPLETE state.
If calling of this command while executing the user data script is
long enough after the token was created, the token may become expired
and signaling Heat will fail.
To fix this issue, write the Heat templates in such a way that
the OS::Heat::WaitConditionHandle resource is created
immediately before the server it will be used with.
Use the depends_on directive in the resource definition to precisely
plan the instantiation of this resource after all other
prerequisite resources for the given server are created.
However, if you anticipate that the execution of the user data script inside the instance will take more than the configured expiration time of the Keystone tokens, a cloud operator should either increase the lifetime of the token or use other methods to signal Heat. For more details, see Heat documentation.