[Bug 2055409] Please test proposed package

James Page 2055409 at bugs.launchpad.net
Fri Jun 28 09:03:53 UTC 2024 

Hello Rodrigo, or anyone else affected,

Accepted horizon into bobcat-proposed. The package will build now and be
available in the Ubuntu Cloud Archive in a few hours, and then in the
-proposed repository.

Please help us by testing this new package. To enable the -proposed
repository:

  sudo add-apt-repository cloud-archive:bobcat-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-bobcat-needed to verification-bobcat-done. If it does
not fix the bug for you, please add a comment stating that, and change
the tag to verification-bobcat-failed. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!

** Changed in: cloud-archive/bobcat
       Status: New => Fix Committed

** Tags added: verification-bobcat-needed

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to horizon in Ubuntu.
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:
  Fix Committed
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:
  Fix Committed
Status in Ubuntu Cloud Archive zed series:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in horizon package in Ubuntu:
  Fix Released
Status in horizon source package in Focal:
  Fix Released
Status in horizon source package in Jammy:
  Fix Released
Status in horizon source package in Mantic:
  Fix Released
Status in horizon source package in Noble:
  Fix Released
Status in horizon source package in Oracular:
  Fix Released

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 (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

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

More information about the Ubuntu-openstack-bugs mailing list