Bug 214714 - Error pushing to RHN (qa). Blocking ASYNC RHSA errata advisory.
Error pushing to RHN (qa). Blocking ASYNC RHSA errata advisory.
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend (Show other bugs)
RHN Stable
All Linux
high Severity medium
: ---
: ---
Assigned To: Bret McMillan
Beth Nackashi
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-11-08 17:36 EST by Eduard Benes
Modified: 2007-03-27 00:52 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-31 15:57:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eduard Benes 2006-11-08 17:36:30 EST
Description of problem:
Errata RHSA-2006:0726 is being blocked. Here is link to the advisory: 


When trying to push data to RHN QA Server, we get this message:

  Done Pushing Files
  Updating issue and update dates to 2006-11-08.
  Pushing to RHN (this could take a while)....

  Error Message:
      Invalid entry: {'changed': '2006-11-02 17:13:13', 'package_name':
  'wireshark', 'rhn_pkgupload': '', 'id': 169120, 'signed_md5sum':
  'b74bd883b6fa0bd1c1aaa87fefb94f23', 'current': 1, 'epoch': 'null', 'ftppath':
  '', 'rhn_channel': ['redhat-advanced-server-i386'], 'key_name': 'master',
  'qa-errata-list@redhat.com', 'collection': '', 'brew_rpm_id': 735621,
  'rhn_shadow_channel': [''], 'arch': 'i386', 'package':
  'wireshark-0.99.4-AS21.1.i386.rpm', 'md5sum':
  'b74bd883b6fa0bd1c1aaa87fefb94f23', 'signed': 'master', 'rhn_beta_channel':
  [''], 'release': '2.1AS', 'key_id': 'db42a60e', 'fullpath':
  Error Class Code: 50
  Error Class Info: Invalid information uploaded to the server
       An error has occurred while processing your request. If this problem
       persists please enter a bug report at bugzilla.redhat.com.
       If you choose to submit the bug report, please be sure to include
       details of what you were trying to do when this error occurred and
       details on how to reproduce this problem.

  Error pushing to RHN (qa):

  Server was http://scripts.back-webqa.redhat.com/BUGZILLA/
  Content-Type: text/html

  Error 	Push to Red Hat Network failed 1.

  Please contact errata-maint@redhat.com if you believe this to be in error.

Steps to Reproduce:
1. Go to the errata advisory. Then go to the Errata Control Center or use this 

2. Push "5. Push Data to RHN QA Server" link in the Update Actions row of the 
Progress Summary table.

3. Hit the "Push errata" button and wait for the result...
Actual results:
Pushing files to RHN fails.

Expected results:
All files should be pushed successfully...

Additional info:
It is blocking ASYNC RHSA errata advisory. 
Look at comment #29
Comment 1 Jon Orris 2006-11-08 20:24:06 EST
I've fixed up the ftp paths. Upon reflection, this occured when I had to
manually create a filelist for this erratum, since there was no ProductListings
data for wireshark.
Comment 2 Pradeep Kilambi 2006-11-09 10:09:44 EST
This is not a bug on RHN's side. The data sent was not valid. Had a discussion
with mjcox on this.

closing as not a bug on our end.
Comment 3 Jon Orris 2006-11-09 14:41:18 EST
This is a bug.

Looking closer at the ftp paths being sent, RHN was only getting sent blank ftp
paths for non SRPM, non -debuginfo packages. No such files are _ever_ sent to
the FTP server, so there is no such thing as a valid path for them.

Comment 4 Jon Orris 2006-11-17 18:16:06 EST
Is there any update on this?

We should not have be taking extra effort to generate phony data for files that
do not ever get pushed to the ftp server. This is bug prone extra effort on our end.

If empty cannot be allowed, then can a simple space or some other character? Is
the RHN side validating that /it/is/a/valid/path ?
Comment 5 Ben Levenson 2006-11-27 12:24:27 EST

Please respond to jorris' comments above.  We really need to know how to proceed
with this before things get too hectic with RHEL-4.5.
Comment 6 Ben Levenson 2006-12-19 02:12:11 EST
We really need a response so we can plan appropriately on our end.
Comment 7 Jon Orris 2007-01-17 11:43:26 EST
Can we please get a response?
Comment 8 Bret McMillan 2007-01-31 15:57:55 EST
I think pradeep's response, while a little brief, was accurate.  I don't recall
the specific field, but I'm pretty sure we were getting sent invalid data, and I
think we agreed to improve the crappy messaging so you would know which field
was broken:


This has been verified as fixed for rhn500 on webqa right now.

In the past, we viewed fullpath as required; we need this to be able to display
info about non-rpm packages on rhn.redhat.com/errata/.  Don't have the example
offhand, but there was an erratum that actually had an updated boot.iso file

In the coming months, I think we'll be coming to you with some ideas on how to
pretty significantly revamp the import procedures, particularly about how we can
have content start to show up in webdev + webqa + stage + dedicated errata env
all at the same time.

Rather than tweaking business logic around the parameters, I'd rather spend the
few immediate cycles we have on bugs like 225251 & 210122... let's stablize
those, then together design the *right way* all this crap should work...

If that's totally insufficient, let's set up a meeting.
Comment 9 Jon Orris 2007-01-31 16:20:54 EST
Right, bug 221885 fixes the error messaging. 

The concern here was the requirement for having a 'valid' ftp path for rpms that
are not actually put on the ftp server. In other words, every rpm that isn't an
SRPM sent to rhn requires a 'valid' path, even though the path is not at all
truly 'valid', in that there is no such directory ever on ftp.redhat.com.

The question we had was
1) Is this really neccessary? We're producing a new version of the errata system
and it would be more convenient to not create fake ftp paths for all the files.

2) Since you seem to imply above that it is neccessary to have an ftp path, at
least for now, the question then is how much validation is done on the path
structure in the rhn import side? 
Does it have to be something very valid looking like:

which is what is sent now, or can we just send:

Jon Orris

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