Activity log for bug #2055409

Date Who What changed Old value New value Message
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