Bug 1267579
| Summary: | Gitlab repositories with disabled or missing filelists.xml database cannot be synced. However tools like yum/reposync are working | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Marcel Gazdík <mgazdik> | ||||
| Component: | Pulp | Assignee: | satellite6-bugs <satellite6-bugs> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Daniel Lobato Garcia <dlobatog> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.1.1 | CC: | bkearney, bmbouter, cwelton, daniele, daviddavis, dkliban, dlobatog, egolov, ehelms, ggainey, hmore, hshukla, iguy, ipanova, jean-pierre.pitout, jmatthew, ktordeur, mgazdik, mhrivnak, mmccune, mtaru, pcreech, rakumar, rchan, rvdwees, satellite6-bugs, ttereshc | ||||
| Target Milestone: | Unspecified | Keywords: | Reopened | ||||
| Target Release: | Unused | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2018-02-21 16:54:17 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1122832 | ||||||
| Attachments: |
|
||||||
|
Comment 4
pulp-infra@redhat.com
2015-10-13 21:00:23 UTC
The Pulp upstream bug priority is at High. Updating the external tracker on this bug. Based on these comments, closing this as wontfix. The git repos are malformed. The Pulp upstream bug status is at NEW. Updating the external tracker on this bug. Hi, Couldn't help notice that GitLab have a "sslcacert" line at the end of their repo config but no place for this configuration in Satellite 6: [gitlab_gitlab-ce] name=gitlab_gitlab-ce baseurl=https://packages.gitlab.com/gitlab/gitlab-ce/el/7/$basearch repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt My question, is this why the metadata cannot be retrieved by Satellite OR are the metdata/repos malformed? Regards, JP Pitout Could installing this cert in a keystore somewhere aleviate this problem? (In reply to jean-pierre.pitout from comment #13) > Could installing this cert in a keystore somewhere aleviate this problem? Hello, the gitlab repositories are malformed, the cert will not help you. For more details of this issue you could check upstream bug. How are they malformed? What is the definition of a well formed yum repo? I can't find a public definition anywhere. If this is malformed why does yum work? (In reply to Ian Koenig from comment #15) > How are they malformed? What is the definition of a well formed yum repo? > I can't find a public definition anywhere. > > If this is malformed why does yum work? feel free to check upstream bug for more info https://pulp.plan.io/issues/1287#note-9 @Ina: Hello, I believe that we should at least tell this to the user while the sync is in progress. As far as I know, it can be checked if the metadata are correct almost in the beginning of the complete process. Since there are downloaded two files - other.db and filelist.db which is the corrupted one. The only step what should be done is checking the integrity, if the filelist.db provided the same list of keys as the other.db (package names if I remember it correctly). And if not, then there should be thrown some exception which will state this instead of letting the process go till it reach the end where all the downloaded (working) data are just removed and everything is pretending that it went great. (In reply to Marcel Gazdík from comment #17) > @Ina: Hello, I believe that we should at least tell this to the user while > the sync is in progress. As far as I know, it can be checked if the metadata > are correct almost in the beginning of the complete process. > Since there are downloaded two files - other.db and filelist.db which is > the corrupted one. The only step what should be done is checking the > integrity, if the filelist.db provided the same list of keys as the other.db > (package names if I remember it correctly). And if not, then there should be > thrown some exception which will state this instead of letting the process > go till it reach the end where all the downloaded (working) data are just > removed and everything is pretending that it went great. Agree, the purpose of the upstream bugfix would be to fail gracefully with some meaningful message. *** Bug 1294196 has been marked as a duplicate of this bug. *** *** Bug 1337662 has been marked as a duplicate of this bug. *** The Pulp upstream bug status is at ASSIGNED. Updating the external tracker on this bug. The Pulp upstream bug status is at POST. Updating the external tracker on this bug. The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug. All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST. The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug. The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug. Verified. Tested with Satellite 6.3 - Snap 13 Check the attached Screenshot, the error about malformed metadata is reported during syncing instead of the original confusing behavior. This was the goal of the Pulp developers as far as I can tell from this thread and https://pulp.plan.io/issues/1287#note-9 It looks like there is no intention from Pulp's side of working around malformed repositories like these, so I'm going to go with verify with the solution proposed, and mark Ina/mhrivnak as NEEDINFO: please answer if there is any intention of working around such repos, and if so, open a BZ o link to it. Thanks. Created attachment 1319967 [details]
Warning message when syncing Gitlab CE repo
we do not plan to workaround this kind of malformed repos. 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/RHSA-2018:0336
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |