[Katello 2.4] Repository sync encouters connection error on specific package and skips follow-ups

Marvin_Beckers · February 25, 2016, 7:52am

Hello Katello/Foreman community,

I've set up a Katello 2.4 instance on CentOS 7 (following the manual
install instructions) to gather some experience working with it.
Installation worked well and I've looked around, read some documentation
and tried to set up tftp boot for hosts. Booting over the network works
well, but I didn't create any repository mirrors before (which renders my
tftp boot useless for the moment, obviously). First of all, let me note the
Katello server is using a proxy for communication with the Internet. It has
been configured during installation. I've set up a product called "CentOS
7" which includes a repository called "Base". The repository is configured
like that:

Label: Base
Type: yum
URL: http://mirror.centos.org/centos/7/os/x86_64/
Yum Metadata Checksum: sha256

Syncing this repository now gives me a strange problem though: I'm
importing not all packages, although the task completes successfully.
Taking a look at the task I made the following observations: Up to a
specific package, it works well. But one package is failing with "A
connection error occured":

{"url"=> "http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm",
"errors"=>["A connection error occurred"]}

After that, countless packages are marked as "Download skipped", including packages such as the kernel (which leads me to the conclusion it's not skipping "unneeded" packages). I suspect the error above is causing that behaviour (maybe because it's a dependency or Katello is following a "connection fails, I abort" policy).

The repository currently holds only 775 packages according to Foreman which
primarily are starting with the letter "a" (which seem to be imported
successfully as a whole) but also include packages alphabetical after
batik (e.g. NetworkManager). The sync task is reporting this after running:

New packages: 8297 (6.19 GB).
Failed to download 8232 packages.

I've suspected our proxy to drop the package (for whatever reason), but the Katello server is able to download the exact package (copy-pasting the URL from the error above) via wget using the same proxy. Honestly, I'm really confused and have little idea how to debug this issue. Unfortunately, it seems like nobody has encountered the same problem (or at least my Google-Fu did not help me finding it). Does anybody have an idea how to debug Katello's weird behaviour or blacklist/skip this package to download the other packages?

Kind regards,

Marvin Beckers

John_Mitsch · February 26, 2016, 2:10pm

Marvin,

Failure to sync one package shouldn't result in all of the other packages
being skipped, so I suspect its not the package that is causing the error.
Does this happen every time you sync this repository?

Next step would be to check /var/log/messages and see if anything related
is there.

-John

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

···

On Thu, Feb 25, 2016 at 2:52 AM, Marvin Beckers wrote:

Hello Katello/Foreman community,

I’ve set up a Katello 2.4 instance on CentOS 7 (following the manual
install instructions) to gather some experience working with it.
Installation worked well and I’ve looked around, read some documentation
and tried to set up tftp boot for hosts. Booting over the network works
well, but I didn’t create any repository mirrors before (which renders my
tftp boot useless for the moment, obviously). First of all, let me note the
Katello server is using a proxy for communication with the Internet. It has
been configured during installation. I’ve set up a product called “CentOS
7” which includes a repository called “Base”. The repository is configured
like that:

Label: Base

Type: yum

URL: http://mirror.centos.org/centos/7/os/x86_64/

Yum Metadata Checksum: sha256

Syncing this repository now gives me a strange problem though: I’m
importing not all packages, although the task completes successfully.
Taking a look at the task I made the following observations: Up to a
specific package, it works well. But one package is failing with “A
connection error occured”:

{“url”=> “http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm”,
“errors”=>[“A connection error occurred”]}

After that, countless packages are marked as “Download skipped”, including packages such as the kernel (which leads me to the conclusion it’s not skipping “unneeded” packages). I suspect the error above is causing that behaviour (maybe because it’s a dependency or Katello is following a “connection fails, I abort” policy).

The repository currently holds only 775 packages according to Foreman
which primarily are starting with the letter “a” (which seem to be imported
successfully as a whole) but also include packages alphabetical after
batik (e.g. NetworkManager). The sync task is reporting this after running:

New packages: 8297 (6.19 GB).
Failed to download 8232 packages.

I’ve suspected our proxy to drop the package (for whatever reason), but the Katello server is able to download the exact package (copy-pasting the URL from the error above) via wget using the same proxy. Honestly, I’m really confused and have little idea how to debug this issue. Unfortunately, it seems like nobody has encountered the same problem (or at least my Google-Fu did not help me finding it). Does anybody have an idea how to debug Katello’s weird behaviour or blacklist/skip this package to download the other packages?

Kind regards,

Marvin Beckers

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Marvin_Beckers · February 29, 2016, 11:37am

Hello John,

I have examined /var/log/messages, unfortunately it offers very little
advice on why the packages are beeing skipped. This is happening when
starting the sync task:

Feb 29 12:00:45 <host> pulp: pulp_rpm.plugins.importers.yum.sync:INFO:
Downloading 8185 RPMs.
Feb 29 12:00:50 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:00:52 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:00:52 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:00:52 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:00:52 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:01:20 <host> pulp: nectar.downloaders.threaded:WARNING: Connection
Error - http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm
could not be reached.

After this, puppet-master is generating a massive amount of SELinux error
messages. As it starts five minutes in I'm not sure this is actually
related at all, but I want to document it.

[root@<host> ~]# tail -n2000 /var/log/messages | grep "invalid context"
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:48 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 <host> puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
[ … ]

[root@<host> ~]# tail -n2000 /var/log/messages | grep "invalid context" |
wc -l
172

After the pulp task finishes, it writes to /var/log/messages again:

Feb 29 12:26:53 <host> pulp: pulp_rpm.plugins.importers.yum.repomd.alternate
:INFO: The content container reported: {'downloads': {'___/primary/___': {
'total_failed': 8128, 'total_succeeded': 57}}, 'total_sources': 0} for base
URL: http://mirror.centos.org/centos/7/os/x86_64/
Feb 29 12:26:53 <host> pulp: pulp_rpm.plugins.importers.yum.sync:INFO:
Downloading additional units.
Feb 29 12:26:53 <host> pulp: requests.packages.urllib3.connectionpool:INFO:
Starting new HTTP connection (1): <proxy-ip>
Feb 29 12:26:57 <host> pulp: pulp_rpm.plugins.importers.yum.sync:INFO: Sync
complete.
Feb 29 12:26:58 <host> pulp: pulp.server.event.http:INFO: (4038-15392) {
'call_report': {u'exception': None, u'task_type': u
'pulp.server.managers.repo.sync.sync', u'task_id': u
'd28c697b-cad9-4cbe-a1e2-3300fbf3b445', u'tags': [u 'pulp:repository:test-CentOS_7-Base', u'pulp:action:sync'], u'finish_time':
None, u'_ns': u'task_status', u'start_time': u'2016-02-29T10:57:13Z', u
'traceback': None, u'spawned_tasks': [], u'progress_report': {u
'yum_importer': {u'content': {u'size_total': 6574173632L, u'items_left': 0,
u'items_total': 8185, u'state': u'FINISHED', u'size_left': 0, u'details': {u
'rpm_total': 8185, u'rpm_done': 8185, u'drpm_total': 0, u'drpm_done': 0}, u
'error_details': [{u'url': u
'http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm'
, u'errors': [u'A connection error occurred']}, {u'url': u
'http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.i686.rpm'
, u'errors': [u'Download skipped']}, {u'url': u
'http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.x86_64.rpm'
, u'errors': [u'Download skipped']}, {u'url': u
'http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glibc-2.12-4.el7.centos.x86_64.rpm'
, u'errors': [u'Download skipped']} […]

The list goes on about all 8000+ packages that were skipped. As you can
see, it sucessfully downloaded 57 more packages (I can confirm this as
every re-run adds a few more packages). I have absolutely no idea why it is
possible to download a few more packages. If there is any more I can
provide, I'll do. To be honest, this really confuses me and I'm thinking
about setting up Foreman again (as it's only a test environment anyway) and
check if the problem persists.

Marvin

John_Mitsch · February 29, 2016, 4:03pm

Marvin,

I talked to the pulp team about this, and this could be related to a bug
that they have been seeing recently https://pulp.plan.io/issues/1210

Do you see BadStatusLine anywhere in /var/log/messages?

They are adding logging in a future version for better debugging of these
cases, but that isn't available in your version of pulp unfortunately. I
would go with setting up Foreman again as you suggested and seeing if the
problem persists (please report back if that is the case).

Thanks

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

···

On Mon, Feb 29, 2016 at 6:37 AM, Marvin Beckers wrote:

Hello John,

I have examined /var/log/messages, unfortunately it offers very little
advice on why the packages are beeing skipped. This is happening when
starting the sync task:

Feb 29 12:00:45 pulp: pulp_rpm.plugins.importers.yum.sync:INFO:
Downloading 8185 RPMs.
Feb 29 12:00:50 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:01:20 pulp: nectar.downloaders.threaded:WARNING:
Connection Error - http://
mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm
could not be reached.

After this, puppet-master is generating a massive amount of SELinux error
messages. As it starts five minutes in I’m not sure this is actually
related at all, but I want to document it.

[root@ ~]# tail -n2000 /var/log/messages | grep "invalid context"
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_etc_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:47 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_var_lib_t:s0
Feb 29 12:06:48 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
Feb 29 12:06:48 puppet-master[6293]:
/etc/selinux/targeted/contexts/files/file_contexts: invalid context
system_u:object_r:puppet_log_t:s0
[ … ]

[root@ ~]# tail -n2000 /var/log/messages | grep “invalid context” |
wc -l
172

After the pulp task finishes, it writes to /var/log/messages again:

Feb 29 12:26:53 pulp: pulp_rpm.plugins.importers.yum.repomd.
alternate:INFO: The content container reported: {‘downloads’: {
’___/primary/___’: {‘total_failed’: 8128, ‘total_succeeded’: 57}},
‘total_sources’: 0} for base URL: http://
mirror.centos.org/centos/7/os/x86_64/
Feb 29 12:26:53 pulp: pulp_rpm.plugins.importers.yum.sync:INFO:
Downloading additional units.
Feb 29 12:26:53 pulp: requests.packages.urllib3.connectionpool:INFO
: Starting new HTTP connection (1):
Feb 29 12:26:57 pulp: pulp_rpm.plugins.importers.yum.sync:INFO:
Sync complete.
Feb 29 12:26:58 pulp: pulp.server.event.http:INFO: (4038-15392) {
‘call_report’: {u’exception’: None, u’task_type’: u
’pulp.server.managers.repo.sync.sync’, u’task_id’: u
’d28c697b-cad9-4cbe-a1e2-3300fbf3b445’, u’tags’: [u ‘pulp:repository:test-CentOS_7-Base’, u’pulp:action:sync’], u’finish_time’
: None, u’_ns’: u’task_status’, u’start_time’: u’2016-02-29T10:57:13Z’, u
’traceback’: None, u’spawned_tasks’: [], u’progress_report’: {u
’yum_importer’: {u’content’: {u’size_total’: 6574173632L, u’items_left’: 0
, u’items_total’: 8185, u’state’: u’FINISHED’, u’size_left’: 0, u’details’
: {u’rpm_total’: 8185, u’rpm_done’: 8185, u’drpm_total’: 0, u’drpm_done’:
0}, u’error_details’: [{u’url’: u’
http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm
’, u’errors’: [u’A connection error occurred’]}, {u’url’: u’
http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.i686.rpm
’, u’errors’: [u’Download skipped’]}, {u’url’: u’
http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.x86_64.rpm
’, u’errors’: [u’Download skipped’]}, {u’url’: u’
http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glibc-2.12-4.el7.centos.x86_64.rpm
’, u’errors’: [u’Download skipped’]} […]

The list goes on about all 8000+ packages that were skipped. As you can
see, it sucessfully downloaded 57 more packages (I can confirm this as
every re-run adds a few more packages). I have absolutely no idea why it is
possible to download a few more packages. If there is any more I can
provide, I’ll do. To be honest, this really confuses me and I’m thinking
about setting up Foreman again (as it’s only a test environment anyway) and
check if the problem persists.

Marvin

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Marvin_Beckers · March 1, 2016, 11:11am

John,

thank you very much for forwarding my issue. Unfortunately, I'm not seeing
BadStatusLine in /var/log/messages. The only message related to nectar is:

[root@<host> ~]# cat /var/log/messages | grep nectar
Feb 29 12:01:20 <host> pulp: nectar.downloaders.threaded:WARNING: Connection
Error - http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm
could not be reached.

I'll set up a new instance of Katello this week and report back to you. I
also noticed wget is behaving a bit weird when downloading this package by
hand: It pauses an unexpected amount of time at 99% (but finishes the
download after that pause) which might indicate our proxy causes a timeout
for pulp/nectar. I'm not really sure about that. If the problem persists
after a clean install I'll blame our infrastructure.

Marvin

···

Am Montag, 29. Februar 2016 17:03:35 UTC+1 schrieb John Mitsch: > > Marvin, > > I talked to the pulp team about this, and this could be related to a bug > that they have been seeing recently https://pulp.plan.io/issues/1210 > > Do you see BadStatusLine anywhere in /var/log/messages? > > They are adding logging in a future version for better debugging of these > cases, but that isn't available in your version of pulp unfortunately. I > would go with setting up Foreman again as you suggested and seeing if the > problem persists (please report back if that is the case). > > Thanks > > John Mitsch > Red Hat Engineering > (860)-967-7285 > irc: jomitsch > > On Mon, Feb 29, 2016 at 6:37 AM, Marvin Beckers > wrote: > >> Hello John, >> >> I have examined /var/log/messages, unfortunately it offers very little >> advice on *why* the packages are beeing skipped. This is happening when >> starting the sync task: >> >> Feb 29 12:00:45 pulp: pulp_rpm.plugins.importers.yum.sync:INFO: >> Downloading 8185 RPMs. >> Feb 29 12:00:50 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:00:52 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:01:20 pulp: nectar.downloaders.threaded:WARNING: >> Connection Error - http:// >> mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm >> could not be reached. >> >> After this, puppet-master is generating a massive amount of SELinux error >> messages. As it starts five minutes in I'm not sure this is actually >> related at all, but I want to document it. >> >> [root@ ~]# tail -n2000 /var/log/messages | grep "invalid context" >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_etc_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_etc_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_etc_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_etc_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_var_lib_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_var_lib_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_var_lib_t:s0 >> Feb 29 12:06:47 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_var_lib_t:s0 >> Feb 29 12:06:48 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_log_t:s0 >> Feb 29 12:06:48 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_log_t:s0 >> Feb 29 12:06:48 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_log_t:s0 >> Feb 29 12:06:48 puppet-master[6293]: >> /etc/selinux/targeted/contexts/files/file_contexts: invalid context >> system_u:object_r:puppet_log_t:s0 >> [ ... ] >> >> [root@ ~]# tail -n2000 /var/log/messages | grep "invalid context" | >> wc -l >> 172 >> >> After the pulp task finishes, it writes to /var/log/messages again: >> >> Feb 29 12:26:53 pulp: pulp_rpm.plugins.importers.yum.repomd. >> alternate:INFO: The content container reported: {'downloads': { >> '___/primary/___': {'total_failed': 8128, 'total_succeeded': 57}}, >> 'total_sources': 0} for base URL: http:// >> mirror.centos.org/centos/7/os/x86_64/ >> Feb 29 12:26:53 pulp: pulp_rpm.plugins.importers.yum.sync:INFO: >> Downloading additional units. >> Feb 29 12:26:53 pulp: requests.packages.urllib3.connectionpool: >> INFO: Starting new HTTP connection (1): >> Feb 29 12:26:57 pulp: pulp_rpm.plugins.importers.yum.sync:INFO: >> Sync complete. >> Feb 29 12:26:58 pulp: pulp.server.event.http:INFO: (4038-15392) { >> 'call_report': {u'exception': None, u'task_type': u >> 'pulp.server.managers.repo.sync.sync', u'task_id': u >> 'd28c697b-cad9-4cbe-a1e2-3300fbf3b445', u'tags': [u >> 'pulp:repository:test-CentOS_7-Base', u'pulp:action:sync'], u >> 'finish_time': None, u'_ns': u'task_status', u'start_time': u >> '2016-02-29T10:57:13Z', u'traceback': None, u'spawned_tasks': [], u >> 'progress_report': {u'yum_importer': {u'content': {u'size_total': >> 6574173632L, u'items_left': 0, u'items_total': 8185, u'state': u >> 'FINISHED', u'size_left': 0, u'details': {u'rpm_total': 8185, u'rpm_done' >> : 8185, u'drpm_total': 0, u'drpm_done': 0}, u'error_details': [{u'url': u >> ' >> http://mirror.centos.org/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm >> ', u'errors': [u'A connection error occurred']}, {u'url': u' >> http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.i686.rpm >> ', u'errors': [u'Download skipped']}, {u'url': u' >> http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glew-1.9.0-7.el7.x86_64.rpm >> ', u'errors': [u'Download skipped']}, {u'url': u' >> http://mirror.centos.org/centos/7/os/x86_64/Packages/compat-glibc-2.12-4.el7.centos.x86_64.rpm >> ', u'errors': [u'Download skipped']} [...] >> >> The list goes on about all 8000+ packages that were skipped. As you can >> see, it sucessfully downloaded 57 more packages (I can confirm this as >> every re-run adds a few more packages). I have absolutely no idea why it is >> possible to download a few more packages. If there is any more I can >> provide, I'll do. To be honest, this really confuses me and I'm thinking >> about setting up Foreman again (as it's only a test environment anyway) and >> check if the problem persists. >> >> Marvin >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > >

Marvin_Beckers · March 8, 2016, 7:18am

Sorry for taking so long to answer, here are my observations on a fresh
install of Katello:

The issue persists with multiple packages. I was able to import the CentOS
7 Extra repository without issue, but it's a small repository and contains
only a few hundred packages. Base and Update both fail the familiar way.
Examining the logs I was not able to find any new meaningful information,
it's the same problem as before.

As I pointed out before, using wget to download this package results in a
long pause at 99% - Therefore I assume this is kind of a timeout problem
with our proxy infrastructure. The wget download completes eventually, but
I guess pulp is unable to handle this timeout (or delay, or whatever
exactly it is). I've skimmed the pulp docs but wasn't able to find any
information about a timeout value (or something similar).

Marvin

John_Mitsch · March 8, 2016, 1:56pm

Marvin,

Thanks for following up on that, it sounds like it could be a possible
timeout issue as you are suggesting. Pulp does have timeout values through
nectar here

github.com

pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33


as well as its configuration. Instances of this class are used by the
download factory to determine which download backend to use.
"""
def __init__(
        self, max_concurrent=None, basic_auth_username=None, basic_auth_password=None,
        ssl_ca_cert=None, ssl_ca_cert_path=None, ssl_client_cert=None,
        ssl_client_cert_path=None, ssl_client_key=None, ssl_client_key_path=None,
        ssl_validation=True, proxy_url=None, proxy_port=None, proxy_username=None,
        proxy_password=None, max_speed=None, headers=None, buffer_size=None,
        progress_interval=None, use_hard_links=False, use_sym_links=False,
        connect_timeout=6.05, read_timeout=27):
    """
    Initialize the DownloaderConfig. All parameters are optional. Not all downloaders use each
    of the configuration items, so for each parameter documented below, the downloaders that
    use it are listed in parenthesis.


    :param max_concurrent:       maximum number of downloads to run concurrently (Threaded)
    :type  max_concurrent:       int
    :param basic_auth_username:  http basic auth username (basic_auth_password must also be
                                 provided) (Threaded)
    :type  basic_auth_username:  basestring

Unfortunately there is no way to change this in pulp, so if you are
feeling brave you can edit the file (which should be
in /usr/lib/python<version>/site-packages/nectar/config.py) and change
connect_timeout and read_timeout values. The pulp developer I talked to
was unsure which one would be timing out for you, so you would have to
fiddle with both.

There is still the possibility this is related to
https://pulp.plan.io/issues/1210. even though we aren't seeing
BadStatusLine in the logs, that might not be in the logs for pulp 2.6.

Let me know if you decide to play with the timeout values and what you find
if so.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

···

On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers wrote:

Sorry for taking so long to answer, here are my observations on a fresh
install of Katello:

The issue persists with multiple packages. I was able to import the CentOS
7 Extra repository without issue, but it’s a small repository and contains
only a few hundred packages. Base and Update both fail the familiar way.
Examining the logs I was not able to find any new meaningful information,
it’s the same problem as before.

As I pointed out before, using wget to download this package results in a
long pause at 99% - Therefore I assume this is kind of a timeout problem
with our proxy infrastructure. The wget download completes eventually, but
I guess pulp is unable to handle this timeout (or delay, or whatever
exactly it is). I’ve skimmed the pulp docs but wasn’t able to find any
information about a timeout value (or something similar).

Marvin

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Marvin_Beckers · March 9, 2016, 9:33am

John,

Thanks to your advice I was able to resolve the issue. The timeout values
you pointed out are the source of my problem. I've set read_timeout to a
much higher value (600) and Katello now syncs all repositories without any
problem. It might be useful to expose these timeout values via some kind of
configuration file (does pulp have a dedicated configuration file?), but
for what it's worth this seems to be a rather obscure problem.

Thank you very much for your help and effort, I very much appreciate it.

Marvin

···

Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch: > > Marvin, > > Thanks for following up on that, it sounds like it could be a possible > timeout issue as you are suggesting. Pulp does have timeout values through > nectar here > https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33 > Unfortunately there is no way to change this in pulp, so if you are > feeling brave you can edit the file (which should be > in /usr/lib/python/site-packages/nectar/config.py) and change > connect_timeout and read_timeout values. The pulp developer I talked to > was unsure which one would be timing out for you, so you would have to > fiddle with both. > > There is still the possibility this is related to > https://pulp.plan.io/issues/1210. even though we aren't seeing > BadStatusLine in the logs, that might not be in the logs for pulp 2.6. > > Let me know if you decide to play with the timeout values and what you > find if so. > > > John Mitsch > Red Hat Engineering > (860)-967-7285 > irc: jomitsch > > On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers > wrote: > >> Sorry for taking so long to answer, here are my observations on a fresh >> install of Katello: >> >> The issue persists with multiple packages. I was able to import the >> CentOS 7 Extra repository without issue, but it's a small repository and >> contains only a few hundred packages. Base and Update both fail the >> familiar way. Examining the logs I was not able to find any new meaningful >> information, it's the same problem as before. >> >> As I pointed out before, using wget to download this package results in a >> long pause at 99% - Therefore I assume this is kind of a timeout problem >> with our proxy infrastructure. The wget download completes eventually, but >> I guess pulp is unable to handle this timeout (or delay, or whatever >> exactly it is). I've skimmed the pulp docs but wasn't able to find any >> information about a timeout value (or something similar). >> >> Marvin >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > >

John_Mitsch · March 9, 2016, 1:24pm

Marvin,

Glad to hear you got everything sorted out! I mentioned this issue to
someone the pulp team and suggested having the timeout variables available
to the users.

Thanks,
John

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

···

On Wed, Mar 9, 2016 at 4:33 AM, Marvin Beckers wrote:

John,

Thanks to your advice I was able to resolve the issue. The timeout values
you pointed out are the source of my problem. I’ve set read_timeout to
a much higher value (600) and Katello now syncs all repositories without
any problem. It might be useful to expose these timeout values via some
kind of configuration file (does pulp have a dedicated configuration
file?), but for what it’s worth this seems to be a rather obscure problem.

Thank you very much for your help and effort, I very much appreciate it.

Marvin

Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch:

Marvin,

Thanks for following up on that, it sounds like it could be a possible
timeout issue as you are suggesting. Pulp does have timeout values through
nectar here
https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33
Unfortunately there is no way to change this in pulp, so if you are
feeling brave you can edit the file (which should be
in /usr/lib/python/site-packages/nectar/config.py) and change
connect_timeout and read_timeout values. The pulp developer I talked to
was unsure which one would be timing out for you, so you would have to
fiddle with both.

There is still the possibility this is related to
https://pulp.plan.io/issues/1210. even though we aren’t seeing
BadStatusLine in the logs, that might not be in the logs for pulp 2.6.

Let me know if you decide to play with the timeout values and what you
find if so.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers becker...@gmail.com >> wrote:

Sorry for taking so long to answer, here are my observations on a fresh
install of Katello:

The issue persists with multiple packages. I was able to import the
CentOS 7 Extra repository without issue, but it’s a small repository and
contains only a few hundred packages. Base and Update both fail the
familiar way. Examining the logs I was not able to find any new meaningful
information, it’s the same problem as before.

As I pointed out before, using wget to download this package results in
a long pause at 99% - Therefore I assume this is kind of a timeout problem
with our proxy infrastructure. The wget download completes eventually, but
I guess pulp is unable to handle this timeout (or delay, or whatever
exactly it is). I’ve skimmed the pulp docs but wasn’t able to find any
information about a timeout value (or something similar).

Marvin

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Michael_Griffin · May 4, 2016, 10:38pm

Just to give a +1 to exposing these timeout values in a config file. We
were having the same problem with certain repositories timing out and
upping the read_timeout and connect_timeout seemed to solve our problem.

···

On Wednesday, March 9, 2016 at 8:24:32 AM UTC-5, John Mitsch wrote: > > Marvin, > > Glad to hear you got everything sorted out! I mentioned this issue to > someone the pulp team and suggested having the timeout variables available > to the users. > > Thanks, > John > > John Mitsch > Red Hat Engineering > (860)-967-7285 > irc: jomitsch > > On Wed, Mar 9, 2016 at 4:33 AM, Marvin Beckers > wrote: > >> John, >> >> Thanks to your advice I was able to resolve the issue. The timeout values >> you pointed out *are* the source of my problem. I've set read_timeout to >> a much higher value (600) and Katello now syncs all repositories without >> any problem. It might be useful to expose these timeout values via some >> kind of configuration file (does pulp have a dedicated configuration >> file?), but for what it's worth this seems to be a rather obscure problem. >> >> Thank you very much for your help and effort, I very much appreciate it. >> >> Marvin >> >> Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch: >>> >>> Marvin, >>> >>> Thanks for following up on that, it sounds like it could be a possible >>> timeout issue as you are suggesting. Pulp does have timeout values through >>> nectar here >>> https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33 >>> Unfortunately there is no way to change this in pulp, so if you are >>> feeling brave you can edit the file (which should be >>> in /usr/lib/python/site-packages/nectar/config.py) and change >>> connect_timeout and read_timeout values. The pulp developer I talked to >>> was unsure which one would be timing out for you, so you would have to >>> fiddle with both. >>> >>> There is still the possibility this is related to >>> https://pulp.plan.io/issues/1210. even though we aren't seeing >>> BadStatusLine in the logs, that might not be in the logs for pulp 2.6. >>> >>> Let me know if you decide to play with the timeout values and what you >>> find if so. >>> >>> >>> John Mitsch >>> Red Hat Engineering >>> (860)-967-7285 >>> irc: jomitsch >>> >>> On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers >>> wrote: >>> >>>> Sorry for taking so long to answer, here are my observations on a fresh >>>> install of Katello: >>>> >>>> The issue persists with multiple packages. I was able to import the >>>> CentOS 7 Extra repository without issue, but it's a small repository and >>>> contains only a few hundred packages. Base and Update both fail the >>>> familiar way. Examining the logs I was not able to find any new meaningful >>>> information, it's the same problem as before. >>>> >>>> As I pointed out before, using wget to download this package results in >>>> a long pause at 99% - Therefore I assume this is kind of a timeout problem >>>> with our proxy infrastructure. The wget download completes eventually, but >>>> I guess pulp is unable to handle this timeout (or delay, or whatever >>>> exactly it is). I've skimmed the pulp docs but wasn't able to find any >>>> information about a timeout value (or something similar). >>>> >>>> Marvin >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Foreman users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to foreman-user...@googlegroups.com. >>>> To post to this group, send email to forema...@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/foreman-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > >

ehelms · May 7, 2016, 2:12pm

Would you mind filing a Redmine issue (
Foreman) so that we can
track it and work with Pulp to expose these options?

···

On Wed, May 4, 2016 at 6:38 PM, Michael Griffin wrote:

Just to give a +1 to exposing these timeout values in a config file. We
were having the same problem with certain repositories timing out and
upping the read_timeout and connect_timeout seemed to solve our problem.

On Wednesday, March 9, 2016 at 8:24:32 AM UTC-5, John Mitsch wrote:

Marvin,

Glad to hear you got everything sorted out! I mentioned this issue to
someone the pulp team and suggested having the timeout variables available
to the users.

Thanks,
John

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Wed, Mar 9, 2016 at 4:33 AM, Marvin Beckers becker...@gmail.com >> wrote:

John,

Thanks to your advice I was able to resolve the issue. The timeout
values you pointed out are the source of my problem. I’ve set
read_timeout to a much higher value (600) and Katello now syncs all
repositories without any problem. It might be useful to expose these
timeout values via some kind of configuration file (does pulp have a
dedicated configuration file?), but for what it’s worth this seems to be a
rather obscure problem.

Thank you very much for your help and effort, I very much appreciate it.

Marvin

Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch:

Marvin,

Thanks for following up on that, it sounds like it could be a possible
timeout issue as you are suggesting. Pulp does have timeout values through
nectar here
https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33
Unfortunately there is no way to change this in pulp, so if you are
feeling brave you can edit the file (which should be
in /usr/lib/python/site-packages/nectar/config.py) and change
connect_timeout and read_timeout values. The pulp developer I talked to
was unsure which one would be timing out for you, so you would have to
fiddle with both.

There is still the possibility this is related to
https://pulp.plan.io/issues/1210. even though we aren’t seeing
BadStatusLine in the logs, that might not be in the logs for pulp 2.6.

Let me know if you decide to play with the timeout values and what you
find if so.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers becker...@gmail.com >>>> wrote:

Sorry for taking so long to answer, here are my observations on a
fresh install of Katello:

The issue persists with multiple packages. I was able to import the
CentOS 7 Extra repository without issue, but it’s a small repository and
contains only a few hundred packages. Base and Update both fail the
familiar way. Examining the logs I was not able to find any new meaningful
information, it’s the same problem as before.

As I pointed out before, using wget to download this package results
in a long pause at 99% - Therefore I assume this is kind of a timeout
problem with our proxy infrastructure. The wget download completes
eventually, but I guess pulp is unable to handle this timeout (or delay, or
whatever exactly it is). I’ve skimmed the pulp docs but wasn’t able to find
any information about a timeout value (or something similar).

Marvin

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University

Michael_Griffin · May 12, 2016, 3:52pm

Eric,

We're not actually using Katello currently. (I can't until the work to
allow Katello to be installed in an existing Foreman installation is
complete). We are using raw pulp. I did go ahead and submit
https://pulp.plan.io/issues/1915 directly to the pulp/nectar Redmine to
work.

···

On Saturday, May 7, 2016 at 10:12:43 AM UTC-4, Eric Helms wrote: > > Would you mind filing a Redmine issue ( > http://projects.theforeman.org/projects/katello/issues/new) so that we > can track it and work with Pulp to expose these options? > > On Wed, May 4, 2016 at 6:38 PM, Michael Griffin > wrote: > >> Just to give a +1 to exposing these timeout values in a config file. We >> were having the same problem with certain repositories timing out and >> upping the read_timeout and connect_timeout seemed to solve our problem. >> >> On Wednesday, March 9, 2016 at 8:24:32 AM UTC-5, John Mitsch wrote: >>> >>> Marvin, >>> >>> Glad to hear you got everything sorted out! I mentioned this issue to >>> someone the pulp team and suggested having the timeout variables available >>> to the users. >>> >>> Thanks, >>> John >>> >>> John Mitsch >>> Red Hat Engineering >>> (860)-967-7285 >>> irc: jomitsch >>> >>> On Wed, Mar 9, 2016 at 4:33 AM, Marvin Beckers >>> wrote: >>> >>>> John, >>>> >>>> Thanks to your advice I was able to resolve the issue. The timeout >>>> values you pointed out *are* the source of my problem. I've set >>>> read_timeout to a much higher value (600) and Katello now syncs all >>>> repositories without any problem. It might be useful to expose these >>>> timeout values via some kind of configuration file (does pulp have a >>>> dedicated configuration file?), but for what it's worth this seems to be a >>>> rather obscure problem. >>>> >>>> Thank you very much for your help and effort, I very much appreciate it. >>>> >>>> Marvin >>>> >>>> Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch: >>>>> >>>>> Marvin, >>>>> >>>>> Thanks for following up on that, it sounds like it could be a possible >>>>> timeout issue as you are suggesting. Pulp does have timeout values through >>>>> nectar here >>>>> https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33 >>>>> Unfortunately there is no way to change this in pulp, so if you >>>>> are feeling brave you can edit the file (which should be >>>>> in /usr/lib/python/site-packages/nectar/config.py) and change >>>>> connect_timeout and read_timeout values. The pulp developer I talked to >>>>> was unsure which one would be timing out for you, so you would have to >>>>> fiddle with both. >>>>> >>>>> There is still the possibility this is related to >>>>> https://pulp.plan.io/issues/1210. even though we aren't seeing >>>>> BadStatusLine in the logs, that might not be in the logs for pulp 2.6. >>>>> >>>>> Let me know if you decide to play with the timeout values and what you >>>>> find if so. >>>>> >>>>> >>>>> John Mitsch >>>>> Red Hat Engineering >>>>> (860)-967-7285 >>>>> irc: jomitsch >>>>> >>>>> On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers >>>>> wrote: >>>>> >>>>>> Sorry for taking so long to answer, here are my observations on a >>>>>> fresh install of Katello: >>>>>> >>>>>> The issue persists with multiple packages. I was able to import the >>>>>> CentOS 7 Extra repository without issue, but it's a small repository and >>>>>> contains only a few hundred packages. Base and Update both fail the >>>>>> familiar way. Examining the logs I was not able to find any new meaningful >>>>>> information, it's the same problem as before. >>>>>> >>>>>> As I pointed out before, using wget to download this package results >>>>>> in a long pause at 99% - Therefore I assume this is kind of a timeout >>>>>> problem with our proxy infrastructure. The wget download completes >>>>>> eventually, but I guess pulp is unable to handle this timeout (or delay, or >>>>>> whatever exactly it is). I've skimmed the pulp docs but wasn't able to find >>>>>> any information about a timeout value (or something similar). >>>>>> >>>>>> Marvin >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Foreman users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to foreman-user...@googlegroups.com. >>>>>> To post to this group, send email to forema...@googlegroups.com. >>>>>> Visit this group at https://groups.google.com/group/foreman-users. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Foreman users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to foreman-user...@googlegroups.com. >>>> To post to this group, send email to forema...@googlegroups.com. >>>> Visit this group at https://groups.google.com/group/foreman-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Eric D. Helms > Red Hat Engineering > Ph.D. Student - North Carolina State University >

John_Mitsch · May 12, 2016, 5:11pm

This was submitted to pulp already here https://pulp.plan.io/issues/1758
if you (and anyone else who is looking for this feature) could +1 on that
issue, it would help let pulp know that users are looking for this feature.

I created a katello issue to track this new feature.
http://projects.theforeman.org/issues/15031

Thanks,

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

···

On Thu, May 12, 2016 at 11:52 AM, Michael Griffin wrote:

Eric,

We’re not actually using Katello currently. (I can’t until the work to
allow Katello to be installed in an existing Foreman installation is
complete). We are using raw pulp. I did go ahead and submit
https://pulp.plan.io/issues/1915 directly to the pulp/nectar Redmine to
work.

On Saturday, May 7, 2016 at 10:12:43 AM UTC-4, Eric Helms wrote:

Would you mind filing a Redmine issue (
Foreman) so that we
can track it and work with Pulp to expose these options?

On Wed, May 4, 2016 at 6:38 PM, Michael Griffin mcgr...@gmail.com >> wrote:

Just to give a +1 to exposing these timeout values in a config file. We
were having the same problem with certain repositories timing out and
upping the read_timeout and connect_timeout seemed to solve our problem.

On Wednesday, March 9, 2016 at 8:24:32 AM UTC-5, John Mitsch wrote:

Marvin,

Glad to hear you got everything sorted out! I mentioned this issue to
someone the pulp team and suggested having the timeout variables available
to the users.

Thanks,
John

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Wed, Mar 9, 2016 at 4:33 AM, Marvin Beckers becker...@gmail.com >>>> wrote:

John,

Thanks to your advice I was able to resolve the issue. The timeout
values you pointed out are the source of my problem. I’ve set
read_timeout to a much higher value (600) and Katello now syncs all
repositories without any problem. It might be useful to expose these
timeout values via some kind of configuration file (does pulp have a
dedicated configuration file?), but for what it’s worth this seems to be a
rather obscure problem.

Thank you very much for your help and effort, I very much appreciate
it.

Marvin

Am Dienstag, 8. März 2016 14:56:53 UTC+1 schrieb John Mitsch:

Marvin,

Thanks for following up on that, it sounds like it could be a
possible timeout issue as you are suggesting. Pulp does have timeout values
through nectar here
https://github.com/pulp/nectar/blob/python-nectar-1.3.3-1/nectar/config.py#L33
Unfortunately there is no way to change this in pulp, so if you
are feeling brave you can edit the file (which should be
in /usr/lib/python/site-packages/nectar/config.py) and change
connect_timeout and read_timeout values. The pulp developer I talked to
was unsure which one would be timing out for you, so you would have to
fiddle with both.

There is still the possibility this is related to
https://pulp.plan.io/issues/1210. even though we aren’t seeing
BadStatusLine in the logs, that might not be in the logs for pulp 2.6.

Let me know if you decide to play with the timeout values and what
you find if so.

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Tue, Mar 8, 2016 at 2:18 AM, Marvin Beckers becker...@gmail.com >>>>>> wrote:

Sorry for taking so long to answer, here are my observations on a
fresh install of Katello:

The issue persists with multiple packages. I was able to import the
CentOS 7 Extra repository without issue, but it’s a small repository and
contains only a few hundred packages. Base and Update both fail the
familiar way. Examining the logs I was not able to find any new meaningful
information, it’s the same problem as before.

As I pointed out before, using wget to download this package results
in a long pause at 99% - Therefore I assume this is kind of a timeout
problem with our proxy infrastructure. The wget download completes
eventually, but I guess pulp is unable to handle this timeout (or delay, or
whatever exactly it is). I’ve skimmed the pulp docs but wasn’t able to find
any information about a timeout value (or something similar).

Marvin

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.