Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 816188 - Katello timeouts when syncing very small repo
Summary: Katello timeouts when syncing very small repo
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: WebUI
Version: Nightly
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-25 13:15 UTC by Lukas Zapletal
Modified: 2018-08-30 21:57 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-02 14:06:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 807720 None None None Never

Description Lukas Zapletal 2012-04-25 13:15:55 UTC
Description of problem:

In our nightly katello tests we are having the following error during sync of a small repo:

Pulp::Task: Request Timeout  (GET /pulp/api/tasks/?state=archived&state=current&id=4e38025e-8ec8-11e1-8c90-525400847278)

The repo I sync is: http://lzap.fedorapeople.org/fakerepos/zoo5/

This is a regression in Pulp perhaps, but we are facing this issue several weeks now.

This is similar issue as https://bugzilla.redhat.com/show_bug.cgi?id=784659 cos it has the same consequence (Katello timeouts during sync), but request is different (GET status instead GET list of repos).

Please note it only happens ONCE, if you sync another repository on the same box, the issue wont happen anymore.

Version-Release number of selected component (if applicable):

pulp-1.0.0-8.el6.noarch
grinder-0.0.144-1.el6.noarch

Steps to Reproduce:
1. Install katello testing.
2. Run our cli test, testsuite "changeset", the very first sync fails.
  
I think it could be also simulated using API call and then with a waiting loop, but installing Katello is easier.

I will attach all relevant log files.

Comment 2 Lukas Zapletal 2012-04-25 13:32:21 UTC
One additional note - if you run changeset suite, the error does not show ALWAYS. I had to put some IO stress to see it again. I simulated this using yum clean all; yum makecache in a bash loop.

Comment 4 Lukas Zapletal 2012-04-25 14:25:05 UTC
I noticed when I comment out this configuration variable:

#post_sync_url = https://localhost/katello/api/repositories/sync_complete

I dont see the issue anymore.

Comment 5 Ivan Necas 2012-04-25 14:38:28 UTC
There was already a bug causing this troubles, see

https://bugzilla.redhat.com/show_bug.cgi?id=807720

but seemed resolved in recent Pulp builds.

Comment 8 Lukas Zapletal 2012-04-25 15:13:30 UTC
I have another reproducer, just create a product with 10+ repos (even small) in it and sync it. Timeout guaranteed:

URL=http://lzap.fedorapeople.org/fakerepos/zoo5/
alias kk='/usr/bin/katello -u admin -p admin'
kk client remember --option org --value ACME_Corporation
kk provider create --name provider
kk product create --name product --provider provider
kk repo create --url $URL --product product --name zoo_A
kk repo create --url $URL --product product --name zoo_B
kk repo create --url $URL --product product --name zoo_C
kk repo create --url $URL --product product --name zoo_D
kk repo create --url $URL --product product --name zoo_E
kk repo create --url $URL --product product --name zoo_F
kk repo create --url $URL --product product --name zoo_G
kk repo create --url $URL --product product --name zoo_G
kk product synchronize --name product

Comment 10 Lukas Zapletal 2012-04-25 16:09:31 UTC
Ok to successfully reproduce this, you need to have ONE THIN instance configured. It works like a charm with TWO+ THIN instances.

This could be considered as workaround, but I guess we should still fix this somehow. I can imagine with two thins, two users could sync in parallel and hit it. The same for N users.

Comment 11 Lukas Zapletal 2012-04-26 12:20:15 UTC
Assigning to me, will tune our installer to setup 2 instances minimum.

Comment 12 Lukas Zapletal 2012-04-26 13:46:04 UTC
So I confirm

pulp-1.1.4-1.el6.noarch

fixes this issue, but I will configure two thins as minimum anyway.

Comment 13 Bryan Kearney 2014-01-21 19:08:05 UTC
Moving to Sat6 to be tracked there. Upstream bugs are moving to redmine.

Comment 16 Corey Welton 2014-05-19 16:02:49 UTC
This is a really old bug, but considering this verified in Satellite-6.0.3-RHEL-6-20140508.1 

I synced/promoted a repo containing only one rpm and it seemed to be OK.

Comment 17 Bryan Kearney 2014-07-02 14:06:02 UTC
This was delivered with 6.0.3, which is the Satellite 6 Beta.


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