Bug 247156
Summary: | RFE: yum grouplist and friends | ||
---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Thorsten Scherf <tscherf> |
Component: | API | Assignee: | Jan Pazdziora <jpazdziora> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brandon Perkins <bperkins> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 420 | CC: | cperry, rhn-bugs, xdmoon |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | sat501 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-08-29 15:32:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Thorsten Scherf
2007-07-05 17:39:33 UTC
This works in hosted, but not against satellite...not sure how this was missed. Reassigning to Shannon. More info... === error_log === Exception exceptions.ValueError: 'I/O operation on closed file' in <bound method File.__del__ of <rhn.transports.File instance at 0xb75b040c>> ignored === access_log === 10.10.76.185 - - [06/Jul/2007:16:41:24 -0400] "POST /XMLRPC HTTP/1.1" 200 901 "-" "rhn.rpclib.py/$Revision: 102540 $" 10.10.76.185 - - [06/Jul/2007:16:41:24 -0400] "POST /XMLRPC HTTP/1.1" 200 1256 "-" "rhn.rpclib.py/$Revision: 102540 $" 10.10.76.185 - - [06/Jul/2007:16:41:24 -0400] "GET /XMLRPC/GET-REQ/rhel-i386-server-5/repodata/repomd.xml HTTP/1.1" 200 1239 "-" "urlgrabber/3.1.0" It looks like hosted supports group* operations because it known about the comps file, which gets pushed to the rhn.redhat.com by releng. adelton | jbowes: I'm working on comps support for Satellite. adelton | jbowes: Could you confirm to me that the comps file is never (not even on hosted) generated from the database, but is just a file on the filesystem? jbowes | adelton: correct adelton | jbowes: So to add the support to the Satellite, I'd better fix satellite-sync to get it from hosted and store somewhere (and the existing logic in the Satellite should kick in just fine, right)? adelton | jbowes: (existing logic to serve it to yum) jbowes | adelton: right adelton | jbowes: Soooo .... adelton | jbowes: What's the best place to store it? Where do you store it in hosted? adelton | jbowes: /var/satellite/comps? jbowes | adelton: it jsut gets uploaded like the isos, so anywhere releng wants to put it (In reply to comment #7) > figure out how to support this in the Satellite? It looks like the comps file is > in the /var/satellite/rhn/kickstart tree ... but that only gets populated with > RHN Tools child channels, not with the parent channel. So it won't work 100 per This is not correct. The kickstart tree comes with the parent directory, and it contains comps*.xml for all the standard RHEL child channels (see comment #12). However, for additional child channels we probably won't get the comps*.xml at all. Fix committed to SVN, branch RELEASE-5.0, revision 118568, and trunk, revision 118569. Added try ... except IOError to SVN, revisions 118665 and 118666. Moving ON_QA because: Satellite 5.0.1-1 and Proxy 5.0.1-1 are now available on webqa hosted channels. Satellite 5.0.1-1 ISOs are now available. Does this issue need an entry in the Satellite 501 release notes? Something along the lines of the following? Let me know if it needs to go into the notes. Thanks! The 'yum grouplist' command now properly lists groups when run on a machine registered to Red Hat Network Satellite. (In reply to comment #23) > > The 'yum grouplist' command now properly lists groups when run on a machine > registered to Red Hat Network Satellite. Yum's group operations now work correctly on a machine registered to RHEL 5 channels on Red Hat Network Satellite. We did a nasty hack to only enable the group functionality for RHEL 5 channels, and all group operations should now work, not just grouplist. Verified with the understanding of the hardcoding/limitations for 5.0.x. Related bug entries look to cover those cases well, so I'm happy to mark this verified for 5.0.1. Release Pending. which release has the fix included? talking about 4.2 releases. |