Description of problem: When deploying via the ucli, there's no way to specify the stack timeout, so the default value (1 hour, configurable via stack_action_timeout in heat.conf) is always used. This is likely to be too low for large deployments, and it's less than the undercloud token expiry (set to 4 hours by default), so we should make it configurable via the CLI. The heatclient convention for this is -t/--timeout So we need something like: openstack overcloud deploy --timeout 240 Which would result in a 4 hour timout (heatclient and the heat API expects the timeout in minutes) The API call stack_args need to have timeout_mins added to them with this value.
Patch midstream https://review.gerrithub.io/#/c/239943/
To clarify the workaround, if this isn't configurable via the CLI, you can set the global timeout in the heat config to a higher value: - Edit /etc/heat/heat.conf on the undercloud to specify stack_action_timeout = 14400 (4 hours in seconds, matches the undercloud keystone token expiration) - Restart the openstack-heat-engine process This will give a global 4 hour timeout when not specifying any timeout via the CLI/API.
I'm moving this back to GA since we have two other fixes we have to merge today anyway. It's been breaking a lot of our QE test deployments, I believe.
Verified: Environment: instack-undercloud-2.1.2-21.el7ost.noarch the timeout is specified in CLI with: -t <min> tested with seeting it to 1 minute - the deployment exited after 1 minute.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2015:1549