yahoo-eng-team team mailing list archive

[Rodrigo Barbieri <2055409@xxxxxxxxxxxxxxxxxx>]

Fix has merged in Caracal/Noble cycle, has been backported upstream to
Bobcat, Antelope and Zed. It needs to have SRU'ed back to Ussuri.

Bobcat, Antelope and Zed could have Point Releases (as long as there one
new tag upstream), but for Yoga, Xena, Wallaby, Victoria and Ussuri it
will necessary to merge the diff directly into SRU code.

For simplicity, I believe it will be better to not wait for Point
releases of Bobcat, Antelope and Zed because just this "waiting for a
new tag" period could take months and all the other releases that don't
have point releases would have to wait on that to get their SRU started

** Also affects: horizon (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: horizon (Ubuntu Mantic)
   Importance: Undecided
       Status: New

** Also affects: horizon (Ubuntu Focal)
   Importance: Undecided
       Status: New

** Also affects: horizon (Ubuntu Jammy)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2055409

Title:
  [SRU] config OPENSTACK_INSTANCE_RETRIEVE_IP_ADDRESSES does not apply
  to instance detail page

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive antelope series:
  New
Status in Ubuntu Cloud Archive bobcat series:
  New
Status in Ubuntu Cloud Archive ussuri series:
  New
Status in Ubuntu Cloud Archive victoria series:
  New
Status in Ubuntu Cloud Archive wallaby series:
  New
Status in Ubuntu Cloud Archive xena series:
  New
Status in Ubuntu Cloud Archive yoga series:
  New
Status in Ubuntu Cloud Archive zed series:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in horizon package in Ubuntu:
  New
Status in horizon source package in Focal:
  New
Status in horizon source package in Jammy:
  New
Status in horizon source package in Mantic:
  New

Bug 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2055409/+subscriptions