2024-02-29 11:36:08 |
Rodrigo Barbieri |
bug |
|
|
added bug |
2024-02-29 11:36:21 |
Rodrigo Barbieri |
horizon: status |
New |
Fix Committed |
|
2024-02-29 13:31:27 |
Rodrigo Barbieri |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well. |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron ports struggle to load the instance list and instance detail pages. The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES allows speeding up the instance list but it is not being used when loading a single instance detail page. By using the config option when loading the instance detail page as well, we speed up instance detail page loading and we have minimal side effects, which are already the same seen when displaying the list (more info about the side effects at [1])
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Regression Potential]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#L2410 |
|
2024-02-29 13:31:41 |
Rodrigo Barbieri |
summary |
config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES does not apply to instance detail page |
[SRU] config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES does not apply to instance detail page |
|
2024-02-29 15:37:19 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/victoria |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/victoria |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/zed |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/zed |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/bobcat |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/bobcat |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/antelope |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/antelope |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/ussuri |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/ussuri |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/xena |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/xena |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/yoga |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/yoga |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
nominated for series |
|
cloud-archive/wallaby |
|
2024-02-29 15:37:42 |
Rodrigo Barbieri |
bug task added |
|
cloud-archive/wallaby |
|
2024-02-29 15:39:06 |
Rodrigo Barbieri |
tags |
|
sts sts-sru-needed |
|
2024-02-29 15:40:34 |
Rodrigo Barbieri |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2024-02-29 16:00:53 |
Rodrigo Barbieri |
bug task added |
|
horizon (Ubuntu) |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
nominated for series |
|
Ubuntu Mantic |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
bug task added |
|
horizon (Ubuntu Mantic) |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
nominated for series |
|
Ubuntu Focal |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
bug task added |
|
horizon (Ubuntu Focal) |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
nominated for series |
|
Ubuntu Jammy |
|
2024-02-29 16:01:29 |
Rodrigo Barbieri |
bug task added |
|
horizon (Ubuntu Jammy) |
|
2024-03-04 12:41:30 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-mantic.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5752373/+files/lp2055409-mantic.debdiff |
|
2024-03-04 12:41:51 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-lunar.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5752374/+files/lp2055409-lunar.debdiff |
|
2024-03-04 12:42:23 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-jammy-zed.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5752375/+files/lp2055409-jammy-zed.debdiff |
|
2024-03-04 12:42:38 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-jammy.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5752376/+files/lp2055409-jammy.debdiff |
|
2024-03-05 10:51:20 |
Rodrigo Barbieri |
attachment removed |
lp2055409-jammy-zed.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5752375/+files/lp2055409-jammy-zed.debdiff |
|
|
2024-03-21 19:32:56 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-focal-xena.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5758151/+files/lp2055409-focal-xena.debdiff |
|
2024-03-21 19:33:15 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-focal-wallaby.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5758152/+files/lp2055409-focal-wallaby.debdiff |
|
2024-03-21 19:33:33 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-focal-victoria.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5758153/+files/lp2055409-focal-victoria.debdiff |
|
2024-03-21 19:33:52 |
Rodrigo Barbieri |
attachment added |
|
lp2055409-focal.debdiff https://bugs.launchpad.net/cloud-archive/+bug/2055409/+attachment/5758154/+files/lp2055409-focal.debdiff |
|
2024-05-17 20:34:14 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Noble |
|
2024-05-17 20:34:14 |
Mauricio Faria de Oliveira |
bug task added |
|
horizon (Ubuntu Noble) |
|
2024-05-17 20:34:14 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Oracular |
|
2024-05-17 20:34:14 |
Mauricio Faria de Oliveira |
bug task added |
|
horizon (Ubuntu Oracular) |
|
2024-05-17 20:34:30 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Oracular): status |
New |
Fix Released |
|
2024-05-17 20:34:42 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Noble): status |
New |
Fix Released |
|
2024-05-20 12:58:26 |
Rodrigo Barbieri |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron ports struggle to load the instance list and instance detail pages. The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES allows speeding up the instance list but it is not being used when loading a single instance detail page. By using the config option when loading the instance detail page as well, we speed up instance detail page loading and we have minimal side effects, which are already the same seen when displaying the list (more info about the side effects at [1])
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Regression Potential]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#L2410 |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron ports struggle to load the instance list and instance detail pages. The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES allows speeding up the instance list but it is not being used when loading a single instance detail page. By using the config option when loading the instance detail page as well, we speed up instance detail page loading and we have minimal side effects, which are already the same seen when displaying the list (more info about the side effects at [1])
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#L2410 |
|
2024-06-05 17:55:23 |
Mauricio Faria de Oliveira |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron ports struggle to load the instance list and instance detail pages. The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES allows speeding up the instance list but it is not being used when loading a single instance detail page. By using the config option when loading the instance detail page as well, we speed up instance detail page loading and we have minimal side effects, which are already the same seen when displaying the list (more info about the side effects at [1])
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#L2410 |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]:
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not retrieve/display IP addresses _somewhere_,
but just _extending_ it from instace _list_ to _details_).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
|
2024-06-05 17:56:32 |
Mauricio Faria de Oliveira |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]:
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not retrieve/display IP addresses _somewhere_,
but just _extending_ it from instace _list_ to _details_).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]:
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not to retrieve/display IP addresses _somewhere_,
just _extending_ it from instance _list_ to _details_ too).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
|
2024-06-05 17:57:44 |
Mauricio Faria de Oliveira |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]:
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not to retrieve/display IP addresses _somewhere_,
just _extending_ it from instance _list_ to _details_ too).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]
(and users were already be subject to this in the list page):
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not to retrieve/display IP addresses _somewhere_,
just _extending_ it from instance _list_ to _details_ too).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
|
2024-06-05 17:58:41 |
Mauricio Faria de Oliveira |
description |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]
(and users were already be subject to this in the list page):
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not to retrieve/display IP addresses _somewhere_,
just _extending_ it from instance _list_ to _details_ too).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _do not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
Setting the config option OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False successfully allows skipping neutron calls when loading the instance list page, therefore speeding up page loading. However, when clicking on an instance and loading the instance details page it still makes the neutron calls, taking a very long time.
The usage of the config option in the code could be adjusted to also be used when loading the instance details page, thus speeding up the page loading there as well.
===============
SRU Description
===============
[Impact]
Environments that have too many neutron (networking) ports are
very slow to load the instance list and instance detail pages.
The existing config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES [1]
can be set to False for not retrieving/displaying IP addresses
(which requires the expensive/slow calls for neutron port list).
That does speed up the loading of the _instance list_ page,
but it's not applied to the _single instance_ detail page,
which remains slow.
By applying the config option when loading the instance detail
page as well, we speed up instance detail page loading and we
have minimal side effects / behavior changes, which are already
the same seen when displaying the instance list anyway (see [1]):
- IP addresses are not included in the detail page
(this is aligned with the option's desired goal).
- Floating IP addresses (if used/available in the deployment)
may take a while to be visible, but a page reload helps [1]
(and users were already be subject to this in the list page):
"""
Note that when disabling the query to neutron it takes some time
until associated floating IPs are visible in the project instance
table and users may reload the table to check them.
"""
This admittedly introduces a behavior change, however in this
case it seems arguably reasonable/acceptable for some reasons:
- The _default behavior_ does not change, as the new change
is gated by the opt-in setting of config option to False.
- The _opt-in behavior_ change (once option is set to False)
is aligned with the _existing_ behavior/goal of that option
(i.e., not to retrieve/display IP addresses _somewhere_,
just _extending_ it from instance _list_ to _details_ too).
- Users opt into that option for it _to address the issue_
of slowness in Horizon when looking at instances (VMs),
but it actually _does not address it_ fully -- i.e., one
page (list) is addressed, but the other (details) is not.
This patch/change improves the behavior/does achieve the
intended goal (address slowness) in the details page too.
- This change is already present in upstream and Noble LTS,
so users would eventually get to it during cloud upgrades.
[Test case]
1. Setting up the env
1a. Deploy openstack env with horizon/openstack-dashboard
1b. Declare and set OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES to False in /etc/openstack-dashboard/local_settings.py and restart apache2
2. Prepare to reproduce the bug
2a. Create a single VM successfully
2b. As we cannot easily create enough ports in the lab to replicate the slowness, we will rely on the message being present in the logs. Therefore, at this step we enable debug in horizon to see the messages. Set DEBUG to True in /etc/openstack-dashboard/local_settings.py and restart apache2.
3. Reproducing the bug
3a. Load the instance list page and verify that the following messages are not present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
3b. Click on the instance to load the detail page and verify that the following messages ARE present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
5. Install package that contains the fixed code
6. Confirm fix
6a. Repeat step 3a.
6b. Click on the instance to load the detail page and verify that the following messages are NOT present in the logs:
GET /v2.0/floatingips?port_id=...
GET /v2.0/ports?tenant_id=...
GET /v2.0/networks?id=...
GET /v2.0/subnets
[Where problems could occur]
The code has tested in upstream CI (without the addition of bug-specific functional tests) from master(Caracal) to stable/zed without any issue captured. Side effects documented at [1]. The code itself is a simple 2-liner with minimal to none chance of regression due to narrow scope of code change impact.
[Other Info]
None.
[1] https://github.com/openstack/horizon/blob/2b03b44f3adeea7e7a8aaab7777cccfa00614301/doc/source/configuration/settings.rst#openstack_instance_retrieve_ip_addresses |
|
2024-06-05 18:12:44 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Mantic): importance |
Undecided |
Medium |
|
2024-06-05 18:12:44 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Mantic): status |
New |
In Progress |
|
2024-06-05 18:12:44 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Mantic): assignee |
|
Rodrigo Barbieri (rodrigo-barbieri2010) |
|
2024-06-05 19:35:30 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Jammy): importance |
Undecided |
Medium |
|
2024-06-05 19:35:30 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Jammy): status |
New |
In Progress |
|
2024-06-05 19:35:30 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Jammy): assignee |
|
Rodrigo Barbieri (rodrigo-barbieri2010) |
|
2024-06-06 12:26:22 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Focal): importance |
Undecided |
Medium |
|
2024-06-06 12:26:22 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Focal): status |
New |
In Progress |
|
2024-06-06 12:26:22 |
Mauricio Faria de Oliveira |
horizon (Ubuntu Focal): assignee |
|
Rodrigo Barbieri (rodrigo-barbieri2010) |
|
2024-06-06 14:59:24 |
Andreas Hasenack |
horizon (Ubuntu Mantic): status |
In Progress |
Fix Committed |
|
2024-06-06 14:59:29 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
2024-06-06 14:59:35 |
Andreas Hasenack |
tags |
sts sts-sru-needed |
sts sts-sru-needed verification-needed verification-needed-mantic |
|
2024-06-06 15:00:50 |
Andreas Hasenack |
horizon (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
2024-06-06 15:00:59 |
Andreas Hasenack |
tags |
sts sts-sru-needed verification-needed verification-needed-mantic |
sts sts-sru-needed verification-needed verification-needed-jammy verification-needed-mantic |
|
2024-06-06 15:01:36 |
Andreas Hasenack |
horizon (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
2024-06-06 15:01:43 |
Andreas Hasenack |
tags |
sts sts-sru-needed verification-needed verification-needed-jammy verification-needed-mantic |
sts sts-sru-needed verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
2024-06-21 13:19:29 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_jammy_yoga_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5791141/+files/bug_2055409_jammy_yoga_verification.txt |
|
2024-06-21 13:20:15 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_mantic_bobcat_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5791142/+files/bug_2055409_mantic_bobcat_verification.txt |
|
2024-06-21 13:20:46 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
sts sts-sru-needed verification-needed verification-needed-focal |
|
2024-06-21 13:21:24 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-needed verification-needed-focal |
sts sts-sru-needed verification-done-jammy verification-done-mantic verification-needed verification-needed-focal |
|
2024-06-21 18:28:45 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_focal_ussuri_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5791239/+files/bug_2055409_focal_ussuri_verification.txt |
|
2024-06-21 18:29:11 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-done-jammy verification-done-mantic verification-needed verification-needed-focal |
sts sts-sru-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed |
|
2024-06-27 19:29:46 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2024-06-27 19:29:41 |
Launchpad Janitor |
horizon (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
2024-06-27 19:30:07 |
Launchpad Janitor |
horizon (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
2024-06-27 19:30:27 |
Launchpad Janitor |
horizon (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
2024-06-28 09:03:56 |
James Page |
cloud-archive/bobcat: status |
New |
Fix Committed |
|
2024-06-28 09:03:58 |
James Page |
tags |
sts sts-sru-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed |
sts sts-sru-needed verification-bobcat-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed |
|
2024-06-28 09:06:11 |
James Page |
cloud-archive/yoga: status |
New |
Fix Committed |
|
2024-06-28 09:06:14 |
James Page |
tags |
sts sts-sru-needed verification-bobcat-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed |
sts sts-sru-needed verification-bobcat-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-yoga-needed |
|
2024-06-28 16:10:35 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_focal_yoga_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5793227/+files/bug_2055409_focal_yoga_verification.txt |
|
2024-06-28 16:10:47 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_jammy_bobcat_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5793228/+files/bug_2055409_jammy_bobcat_verification.txt |
|
2024-06-28 16:11:19 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-bobcat-needed verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-yoga-needed |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-yoga-done |
|
2024-07-01 13:43:30 |
Edward Hope-Morley |
nominated for series |
|
cloud-archive/caracal |
|
2024-07-01 13:43:30 |
Edward Hope-Morley |
bug task added |
|
cloud-archive/caracal |
|
2024-07-01 13:43:53 |
Edward Hope-Morley |
cloud-archive/caracal: status |
New |
Fix Committed |
|
2024-07-08 15:40:40 |
James Page |
cloud-archive/bobcat: status |
Fix Committed |
Fix Released |
|
2024-07-08 15:54:22 |
Rodrigo Barbieri |
cloud-archive/zed: status |
New |
Won't Fix |
|
2024-07-08 15:54:39 |
Rodrigo Barbieri |
cloud-archive/victoria: status |
New |
Won't Fix |
|
2024-07-08 15:54:51 |
Rodrigo Barbieri |
cloud-archive/wallaby: status |
New |
Won't Fix |
|
2024-07-08 15:55:06 |
Rodrigo Barbieri |
cloud-archive/xena: status |
New |
Won't Fix |
|
2024-07-08 16:06:58 |
James Page |
cloud-archive/ussuri: status |
New |
Fix Committed |
|
2024-07-08 16:07:01 |
James Page |
tags |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-yoga-done |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-needed verification-yoga-done |
|
2024-07-08 16:09:06 |
James Page |
cloud-archive/yoga: status |
Fix Committed |
Fix Released |
|
2024-07-09 12:24:31 |
Mauricio Faria de Oliveira |
cloud-archive/antelope: importance |
Undecided |
Medium |
|
2024-07-09 12:24:31 |
Mauricio Faria de Oliveira |
cloud-archive/antelope: status |
New |
Triaged |
|
2024-07-09 14:18:11 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_bionic_ussuri_verification.txt https://bugs.launchpad.net/horizon/+bug/2055409/+attachment/5795628/+files/bug_2055409_bionic_ussuri_verification.txt |
|
2024-07-09 14:18:29 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-needed verification-yoga-done |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
|
2024-07-10 04:11:26 |
James Page |
cloud-archive/antelope: status |
Triaged |
Fix Committed |
|
2024-07-10 04:11:29 |
James Page |
tags |
sts sts-sru-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
sts sts-sru-needed verification-antelope-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
|
2024-07-10 11:16:33 |
Rodrigo Barbieri |
attachment added |
|
bug_2055409_jammy_antelope_verification.txt https://bugs.launchpad.net/cloud-archive/xena/+bug/2055409/+attachment/5795828/+files/bug_2055409_jammy_antelope_verification.txt |
|
2024-07-10 11:17:38 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-antelope-needed verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
sts sts-sru-needed verification-antelope-done verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
|
2024-07-10 11:32:21 |
Rodrigo Barbieri |
cloud-archive/caracal: status |
Fix Committed |
Fix Released |
|
2024-07-10 11:33:25 |
Rodrigo Barbieri |
tags |
sts sts-sru-needed verification-antelope-done verification-bobcat-done verification-done-focal verification-done-jammy verification-done-mantic verification-needed verification-ussuri-done verification-yoga-done |
sts sts-sru-needed verification-antelope-done verification-bobcat-done verification-done verification-done-focal verification-done-jammy verification-done-mantic verification-ussuri-done verification-yoga-done |
|
2024-07-25 14:16:25 |
James Page |
cloud-archive/antelope: status |
Fix Committed |
Fix Released |
|