If you pass a timeout_mins API argument when updating a stack (not currently supported in python-heatclient[1] but is documented in the API docs[2]) we ignore it and use the timeout stored in the DB with the stack on create (whatever was supplied or the default 60mins).
It seems we've got some remaining cfn-isms in the engine causing this, where we treat the timeout as an attribute of the stack rather than something related to the action being performed.
It seems reasonable to provide some means to override the timeout on stack-update, as it would be necessary in the case where you expand the template dramatically on update and the currently stored timeout is insufficient.
Plan to resolve this:
- Stop passing a hard-coded default number from python-heatclient
- If no timeout number is passed on create use the configured default timeout in the engine but store a null value (since the user didn't pass us a specific value)
- On update use the value passed as an argument if available, otherwise the stored value in the DB, or else the configured default?
In the update case its a but unclear what the best behavior is, perhaps we should always ignore the DB value and use the argument or default, but that might cause issues if users pass a large timeout on create and expect it to be respected on update? (It's also a bit unclear what behavior matches what is expected via the CFN compatible API..)
Oops, references:
[1] https:/
[2] http://