Bug 1437197 - Ansible Tower inventory integration is slow
Summary: Ansible Tower inventory integration is slow
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: API
Version: 6.2.6
Hardware: Unspecified
OS: Linux
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Justin Sherrill
QA Contact: Jitendra Yejare
URL:
Whiteboard:
: 1560275 (view as bug list)
Depends On: 1461194 1516244
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-29 17:50 UTC by Michelle Perz
Modified: 2019-06-13 21:26 UTC (History)
23 users (show)

Fixed In Version: katello-installer-base-3.4.5.28-1,tfm-rubygem-katello-3.4.5.62-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-13 13:29:48 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1126 None None None 2018-04-13 13:31:33 UTC
Foreman Issue Tracker 22287 None None None 2018-01-16 16:38:27 UTC
Foreman Issue Tracker 22970 None None None 2018-03-21 19:26:37 UTC

Description Michelle Perz 2017-03-29 17:50:38 UTC
Description of problem:

When using the Ansible Tower built-in Satellite 6 inventory integration, a sync takes roughly 4 and a half hours to complete against 845 hosts. This behavior is identical from the command line using a straight invocation of foreman.py and matching the max_age parameter to what is already set in Tower.  


How reproducible:

Reproducible every time for this customer, but not reproducible for us locally.

Steps to Reproduce:
1. Pull down foreman.py and foreman.ini from https://github.com/ansible/ansible/tree/devel/contrib/inventory directory
2. Populate [foreman] section of foreman.ini with Sat host details.
3. Ensure max_age is set to 60
4. Run time ./foreman.py

Actual results:

CLI run:
real    252m51.541s
user    0m9.319s
sys     0m1.713s

Tower run: 14829.828 aka 247 minutes


Expected results:

Our local tests against half as many hosts were completing in 6 minutes so conservatively 20 minutes for this customer.

Comment 2 Marek Hulan 2017-03-30 10:56:32 UTC
Thanks for the report, could you please provide the output of foreman-debug? Also a production log with debug log level and sql logger enabled would help. Please follow https://access.redhat.com/solutions/2252291 to enable such debugging. Don't forget to revert the changes afterwards, it can produce a lot of logs.

Comment 21 Marek Hulan 2018-01-16 16:38:15 UTC
Created redmine issue http://projects.theforeman.org/issues/22287 from this bug

Comment 24 pm-sat@redhat.com 2018-02-08 19:09:07 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/22287 has been resolved.

Comment 28 Justin Sherrill 2018-03-22 01:24:16 UTC
Sachin, 

yes, checking an ansible inventory against satellite would be great.  10K hosts is probably a good size to test before and after times. 

In addition, we'd need to verify:

1.  after upgrade, on the hosts > content host > details page, the installed product list is still there
2. after upgrade, on the hosts > content host > details > subscriptions page, the compliance reasons right below the status, is still there (you may need to make sure the system is not fully entitled)   An example of  one is "Red Hat Enterprise Linux Server: Not supported by a valid subscription."
3.  When changing the subscription status via the UI (by un-entitling/re-entitling) ensure the compliance reasons will update
4.  When changing the subscription status via sub-man, ensure the compliance reasons will update
5.  If you add a or remove an installed product and run sub-man refresh, it should get reflected in the UI (you can do this by moving /etc/pki/products/* to some other place, or moving it back)

Let me know if you have any questions

Comment 29 Jitendra Yejare 2018-03-27 11:30:08 UTC
@Justin,

I tested this bug with Satellite 6.3.1 snap 1

I observed:


> yes, checking an ansible inventory against satellite would be great.  10K
> hosts is probably a good size to test before and after times. 

Test: Total 1997 content host sync to ansible tower
Result: Took 515 seconds (almost 9 minutes), That's very good improvement
Mark : Pass
 
> In addition, we'd need to verify:
> 
> 1.  after upgrade, on the hosts > content host > details page, the installed
> product list is still there

Result: After the upgrade, the product list was there
Mark : Pass

> 2. after upgrade, on the hosts > content host > details > subscriptions
> page, the compliance reasons right below the status, is still there (you may
> need to make sure the system is not fully entitled)   An example of  one is
> "Red Hat Enterprise Linux Server: Not supported by a valid subscription."

Result: After the upgrade, The compliance reason below status is "not displayed" when the subscription is entitled.
Mark: Fail

> 3.  When changing the subscription status via the UI (by
> un-entitling/re-entitling) ensure the compliance reasons will update

Result: Same as above
Mark : Fail

> 4.  When changing the subscription status via sub-man, ensure the compliance
> reasons will update

Result: Same as above
Mark : Fail

> 5.  If you add a or remove an installed product and run sub-man refresh, it
> should get reflected in the UI (you can do this by moving
> /etc/pki/products/* to some other place, or moving it back)

Result: Adding and removing of installed product is getting reflected correctly

With that said, There is regression with 2.

Shall I Assign this to you ? Does the tests are correct especially with 1997 chosts ?

Comment 30 Justin Sherrill 2018-03-27 13:06:20 UTC
Yeah, feel free to assign to me.  I will need to dig into these failures.

Comment 32 Jitendra Yejare 2018-04-02 06:45:22 UTC
Yes Justin, 

I do have the system to repro this bug. I sent you the details through Email.

Comment 33 Justin Sherrill 2018-04-03 02:23:25 UTC
Hi Jitendra,

Playing around with your reproducer, i wasn't able to reproduce some of your issues

for 2) the compliance reasons only show up when a system isn't fully entitled, and it sounds like you were only looking at an entitled host

for 3) This worked for me just fine (although i did have to refresh the page to see the changes, which is a regression, working on a fix).

for 4) it sounds like maybe 2) wasn't tested correctly, so maybe this one wasn't either?

Do you mind taking a look and confirm that a page refresh makes the compliance reasons show up or disappear when entitling or un-entitling a host?

Comment 34 Justin Sherrill 2018-04-03 16:37:59 UTC
For 3) the issue where i had to refresh to see the compliance reasons update (a very minor issue), i've opened an issue (and pr) upstream: http://projects.theforeman.org/issues/23105

we can pull it in if it is decided.

Comment 35 Jitendra Yejare 2018-04-04 08:15:43 UTC
Sorry Justin, I wanted to say in comment 29 for point 2 - "I reproduced that while the host was not entitled", the word 'not' was missing there.


By the way, I attempted to reproduce the failed points in my last comment 29 and magic happened as I am able to see the compliance reasons now but only after refresh. I am ok with this issue as you have already raised and the issue is out of the scope of this bug.

I am AGREE with what you mentioned in comment 33.

Hence changing the bug status to 'Verified'.

Comment 38 errata-xmlrpc 2018-04-13 13:29:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1126

Comment 39 Pavel Moravec 2018-04-17 18:01:17 UTC
*** Bug 1560275 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.