Bug 1104375
Summary: | Collisions possible in proxy lookaside cache | |||
---|---|---|---|---|
Product: | [Community] Spacewalk | Reporter: | Stephen Herr <sherr> | |
Component: | Proxy Server | Assignee: | Stephen Herr <sherr> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Satellite QA List <satqe-list> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 2.2 | |||
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | spacewalk-proxy-2.2.4-1 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1105282 (view as bug list) | Environment: | ||
Last Closed: | 2014-07-17 08:41:34 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: | 1105282, 1119298 |
Description
Stephen Herr
2014-06-03 20:57:16 UTC
Spacewalk can solve this problem by incorporating the checksum in the path because the checksum is calculated when the rpm is first imported, and then the path is simply saved in the database. Subsequent requests will simply lookup the path from the database and find the appropriate file. This will not work for Proxy. Proxy could calculate the checksum at rpm import time, but later requests do not contain the checksum information and Proxy has no database to store the path in. Proxy receives GET requests that contain channel-label and package-name only for identifying information. Theoretically we organize the Proxy lookaside cache such that the channel-label was part of the path; this would solve this immediate problem (a given channel can only contain one rpm with a given nevra), however it's a bad idea. That would mean that we are storing duplicate copies of the rpm for every original, cloned, and custom channel they're in, and that the user would have to upload the rpm into the cache once for every channel instead of just uploading it once. This would cause the Proxy filesystem to have to be many times the size of the Spacewalk filesystem in some use cases. Theoretically we could implement a new function call up to the Spacewalk to get the rpm's checksum and use it to calculate the path, however this is also probably a bad idea. The Proxy lookaside cache is meant to be a very fast local lookup, it happens before we even hit squid to see what it has cached. It makes little sense to me to include a call up to Spacewalk (over a potentially high-latency network) for every single request, even for those files we eventually do find in the lookaside or squid caches. However that leaves no other feasible options that I can see. We simply don't have enough information in the request to determine which of the same-nevra-different-checksum rpms is desired. Proxy has no database, no permanent channel-to-package mappings, no permanent statefull information of any kind. Where does that leave us? Simply documenting that you may not store rpms with the same nevra but different checksums on the proxy, and that once you store an rpm with a given nevra in the lookaside cache it will be returned for all requests for any channel, regardless of if that's the rpm that's actually in that channel? Other options that I don't see? I found another solution. The Proxy does get a channel -> package map from Spacewalk and use it to generate a cached list of package -> path mappings. I'll have to make a new api method on Spacewalk that also returns checksum information for the packages, and then ensure that updated Proxies call that and use the information appropriately to generate paths. Committing to Spacewalk master: c4c8d58e132343f11e975a55ccd1cb96c5ca5ee9 We should use a path structure that avoids collisions if: 1) The upstream server is new enough to have implemented bz 1105282 2) This is not a source rpm. Unfortunately for source rpms there's no relaible way to find it again later, they'll just have to use the old collidable path structure. And: 632dd273e0eeb73f53dc6e55fd6b193956214b13 Checkstyle fixes: 5fead8b46b0930c53933ba05aa19f28a2db65208 Spacewalk 2.2 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes22 |