| 2020-03-19 08:28:28 |
Bogdan Dobrelya |
bug |
|
|
added bug |
| 2020-03-19 08:28:34 |
Bogdan Dobrelya |
tripleo: importance |
Undecided |
High |
|
| 2020-03-19 08:28:35 |
Bogdan Dobrelya |
tripleo: milestone |
|
ussuri-3 |
|
| 2020-03-19 08:42:13 |
Bogdan Dobrelya |
description |
The --config-download-timeout defines the ansible ssh timeout, while it is given a value of a global timeout of a deployment. Additionally, ansible execution should be also limited via its job_timeout setting |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. Additionally, ansible execution should be also limited via its job_timeout setting |
|
| 2020-03-19 08:57:20 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. Additionally, ansible execution should be also limited via its job_timeout setting |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting. |
|
| 2020-03-19 09:01:20 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting. |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting. |
|
| 2020-03-19 09:01:30 |
Bogdan Dobrelya |
tags |
|
train-backport-potential |
|
| 2020-03-19 09:01:41 |
Bogdan Dobrelya |
tripleo: status |
New |
In Progress |
|
| 2020-03-19 09:01:43 |
Bogdan Dobrelya |
tripleo: assignee |
|
Bogdan Dobrelya (bogdando) |
|
| 2020-03-19 09:09:00 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting. |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502) |
|
| 2020-03-19 09:10:40 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502) |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
|
| 2020-03-19 09:26:51 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions.
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (that may be worth opening another bug)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
|
| 2020-03-19 09:29:59 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (that may be worth opening another bug)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (extracted to https://bugs.launchpad.net/tripleo/+bug/1868075)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
|
| 2020-03-27 14:30:12 |
Bogdan Dobrelya |
tripleo: importance |
High |
Medium |
|
| 2020-04-02 13:15:12 |
Bogdan Dobrelya |
tripleo: importance |
Medium |
High |
|
| 2020-04-02 13:16:23 |
Bogdan Dobrelya |
tags |
train-backport-potential |
stein-backport-potential train-backport-potential |
|
| 2020-04-02 13:17:12 |
Bogdan Dobrelya |
summary |
Timeout settings are misused for config download |
Timeout settings are misused for config download and some workflows |
|
| 2020-04-02 13:17:19 |
Bogdan Dobrelya |
tags |
stein-backport-potential train-backport-potential |
queens-backport-potential stein-backport-potential train-backport-potential |
|
| 2020-04-02 13:28:57 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (extracted to https://bugs.launchpad.net/tripleo/+bug/1868075)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968 |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (extracted to https://bugs.launchpad.net/tripleo/+bug/1868075)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968
The impact is:
While the heat stacks part and the most of workflows are used to be set timeouts properly, the config-download part and a few bare-metal workflows to it wrongly and configure ssh timeout for ansible instead of real deployment timeouts |
|
| 2020-04-03 16:00:57 |
OpenStack Infra |
tripleo: assignee |
Bogdan Dobrelya (bogdando) |
Kevin Carter (kevin-carter) |
|
| 2020-04-03 16:20:02 |
OpenStack Infra |
tripleo: assignee |
Kevin Carter (kevin-carter) |
Bogdan Dobrelya (bogdando) |
|
| 2020-04-04 22:32:08 |
OpenStack Infra |
tripleo: assignee |
Bogdan Dobrelya (bogdando) |
Kevin Carter (kevin-carter) |
|
| 2020-04-06 07:41:08 |
OpenStack Infra |
tripleo: assignee |
Kevin Carter (kevin-carter) |
Bogdan Dobrelya (bogdando) |
|
| 2020-04-06 09:24:51 |
OpenStack Infra |
tags |
queens-backport-potential stein-backport-potential train-backport-potential |
in-stable-train queens-backport-potential stein-backport-potential train-backport-potential |
|
| 2020-04-07 17:32:27 |
OpenStack Infra |
tripleo: status |
In Progress |
Fix Released |
|
| 2020-04-08 10:31:03 |
Bogdan Dobrelya |
description |
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (extracted to https://bugs.launchpad.net/tripleo/+bug/1868075)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968
The impact is:
While the heat stacks part and the most of workflows are used to be set timeouts properly, the config-download part and a few bare-metal workflows to it wrongly and configure ssh timeout for ansible instead of real deployment timeouts |
This continues https://bugs.launchpad.net/tripleo/+bug/1867968
The --config-download-timeout CLI option and the ansible_timeout param of run_ansible_playbook utility define the ansible ssh timeout, while those are given a global timeout of a deployment. The timeout in the scale down workflow is also misused and defines ansible ssh timeout instead of a deployment action timeout.
The update/upgrade -including external- actions should also provide ansible connection (SSH) timeout. That is important to have that parameter for not only day1 but also day2 actions. Let's also inspect if we correctly pass connection timeout in workflows for all day1/2 actions. (extracted to https://bugs.launchpad.net/tripleo/+bug/1868075)
Additionally, ansible execution should be also limited via its job_timeout setting (https://bugzilla.redhat.com/show_bug.cgi?id=1801502)
See also related bug https://bugs.launchpad.net/tripleo/+bug/1867968
The impact is:
While the heat stacks part and the most of workflows are used to be set timeouts properly, the config-download part and a few bare-metal workflows to it wrongly and configure ssh timeout for ansible instead of real deployment timeouts |
|
| 2020-04-08 10:32:45 |
Bogdan Dobrelya |
tags |
in-stable-train queens-backport-potential stein-backport-potential train-backport-potential |
config-download in-stable-train queens-backport-potential stein-backport-potential train-backport-potential |
|
| 2020-04-15 00:29:49 |
OpenStack Infra |
tags |
config-download in-stable-train queens-backport-potential stein-backport-potential train-backport-potential |
config-download in-stable-stein in-stable-train queens-backport-potential stein-backport-potential train-backport-potential |
|
