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.
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.
Created redmine issue http://projects.theforeman.org/issues/22287 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/22287 has been resolved.
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
@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 ?
Yeah, feel free to assign to me. I will need to dig into these failures.
Yes Justin, I do have the system to repro this bug. I sent you the details through Email.
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?
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.
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'.
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
*** Bug 1560275 has been marked as a duplicate of this bug. ***