tripleo-ansible-inventory is too slow: it takes more than 2 minutes to generate an inventory containing 1 undercloud + 1 controller + 1 compute

Bug #1715428 reported by Marius Cornea
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Fix Released
High
Steven Hardy

Bug Description

Description of problem:
tripleo-ansible-inventory takes more than 2 minutes to generate an inventory containing 1 undercloud + 1 controller + 1 compute.

Version-Release number of selected component (if applicable):
openstack-tripleo-validations-7.2.1-0.20170818153714.85b7569.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Run tripleo-ansible-inventory --list

Actual results:
It takes almost 2 minutes to display the inventory for a minimal deployment.

Expected results:
It should be a matter of seconds to generate the inventory.

Additional info:

In upgrades we use use the inventory for upgrading non controller nodes and this step adds a pretty high delay per node upgrade.

Revision history for this message
Steven Hardy (shardy) wrote :

Confirmed locally, I'm working on a fix which reverts to using stack show instead of multiple stack output show calls

Changed in tripleo:
assignee: nobody → Steven Hardy (shardy)
milestone: pike-rc2 → queens-1
status: New → Confirmed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-validations (master)

Fix proposed to branch: master
Review: https://review.openstack.org/501354

Changed in tripleo:
status: Confirmed → In Progress
Revision history for this message
Steven Hardy (shardy) wrote :

With that patch I see time go from over 1 minute to this:

(undercloud) [stack@undercloud ~]$ time tripleo-ansible-inventory --list 2>&1 > /dev/null

real 0m12.608s
user 0m0.413s
sys 0m0.077s

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on tripleo-validations (master)

Change abandoned by Steven Hardy (<email address hidden>) on branch: master
Review: https://review.openstack.org/501354
Reason: Abandoned for https://review.openstack.org/#/q/I0fcde3f7641ccc26f045fcc8146ec4067e45330c,n,z

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tripleo-validations (stable/pike)

Reviewed: https://review.openstack.org/501603
Committed: https://git.openstack.org/cgit/openstack/tripleo-validations/commit/?id=efe8a7251fc0737ea76faceef229a7ce934a8f60
Submitter: Jenkins
Branch: stable/pike

commit efe8a7251fc0737ea76faceef229a7ce934a8f60
Author: Ben Nemec <email address hidden>
Date: Tue Aug 29 16:56:43 2017 +0000

    Lazy load the entire stack instead of single outputs

    Each call to output_show is taking around 15 seconds for me, which
    causes the entire inventory process to take 90 seconds or more.
    Loading the entire stack with outputs resolved only takes around
    20 seconds and keeps the total runtime of the dynamic inventory
    much shorter overall because it only has to be done once.

    The stack is lazy loaded at the first call to __getitem__ because it
    seems that Ansible instantiates multiple copies of the class but
    never actually looks anything up in some of them, so if we load the
    stack in the constructor we just waste time retrieving it
    unnecessarily.

    This change has reduced the time it takes to run even simple ad-hoc
    commands against a small 2 node inventory from 2.5-3 minutes to
    45 seconds (which is still too long IMHO, but a step in the right
    direction).

    Closes-Bug: #1715428
    Change-Id: I0fcde3f7641ccc26f045fcc8146ec4067e45330c
    (cherry picked from commit 0dec2d8afabd52e69021f6fbf3424ea719557868)

tags: added: in-stable-pike
Steven Hardy (shardy)
Changed in tripleo:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/tripleo-validations 7.4.0

This issue was fixed in the openstack/tripleo-validations 7.4.0 release.

Steven Hardy (shardy)
Changed in tripleo:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.