Hide Forgot
Ok, the setup to explain this is a headache, so bear with me. Reproduction: - Create a protected repo and associate it with a CDS. Make sure to give it a bad consumer certificate; the CDS sync of the repo from Pulp should fail. - Update the repo after attempting a CDS sync with a valid cert. - The valid cert should be used by the CDS on the next sync, but in this bug, it's still using the old cert. - Restart goferd on the CDS. - Now try the CDS sync again. It should be successful. Explanation: On each sync call to the CDS, all of the necessary information is being sent, which includes repo auth. So on the second sync call above, it should have been sent the updated certificate. I'm pretty sure that's the case. After the second sync as described above, the certificates on disk were still the invalid ones. That makes me think that the attempted smarts in the CDS code is busted. Those smarts, from what I can remember without looking in the code, diff the new and old certificates so we don't unnecessarily overwrite the same file on each sync. I'd guess that's where the bug is. I'd also guess that restarting goferd clears whatever in memory cache of those certs that the CDS is doing and causes the new ones to be correctly written. Less possible is that grinder/curl/someone is caching the certificates passed in on the first call and not re-reading them on subsequent calls (namely, the later call with the right cert). Since the certs on disk are still the invalid ones, I don't _think_ this is the case, but it can't be ruled out just yet.
After some investigation, I'm closing this as won't fix: - The majority of the code involved is going to change with generic content. - The use case to produce it is pretty rare. - The work around is pretty simple. Time is better spent getting the new code in place than dealing with the existing code.