Refactor #1989
closed
Refactor errata to be related to repositories
0%
Description
We have a lot of issues that relate to Errata that have served to greatly improve our understanding of Errata. We should apply this knowledge to the current Errata implementation, preferably in a way that works in harmony with the pending shift to a relational DB.
Without going too much into specifics, all of these issues lead me to believe that errata are really repository metadata, not content units. They are closely related to the packages in a repository, and our attempts to efficiently combine errata data into a single content unit that represents all known errata information across multiple repos have had a profound negative impact on errata publishing performance.
Currently, the errata unit key is just the errata_id. My proposed refactor is, if possible, to include repo_id in the identity of an errata. While this sounds simple (and it is, moving forward), what makes this tricky is backward compatability, and how to handle existing errata pre-refactor, which may not have any information that can be used to associate errata with their feed repositories.
Here are some of the issues, with #858 capturing a lot of the specifics about what errata really are, and some thoughts about how we should treat them:
https://pulp.plan.io/issues/858
https://pulp.plan.io/issues/1366
https://pulp.plan.io/issues/1548
https://pulp.plan.io/issues/1898
https://pulp.plan.io/issues/1949
Updated by semyers over 8 years ago
Some IRC discussion bits, where asmacdo asked a question about my statement above that errata are not content units:
15:19 <smyers> This isn't a story, but it is an enhancement. I'm not sure how (or if) it can be written as a story: https://pulp.plan.io/issues/1989
15:19 <@pulpbot> Title: Refactor #1989: Refactor errata to be related to repositories - RPM Support - Pulp (at pulp.plan.io)
15:21 <smyers> But I think it's pretty important for pulp 3, and so it's work getting on a pulp 2 sprint if we can as part of making changes in 2 to make migration to 3 easier.
15:21 <smyers> s/work/worth
15:21 smyers: But I think it's pretty important for pulp 3, and so it's worth getting on a pulp 2 sprint if we can as part of making changes in 2 to make migration to 3 easier.
15:22 <asmacdo> smyers, this would not be backwards incompatible?
15:23 <asmacdo> seems like it would require forking for 3 to me
15:23 <smyers> why?
15:24 <asmacdo> i might be wrong, but removing a content unit and making it metadata just sounds backwards incompatible
15:24 <asmacdo> unless you mean that ^ is the goal, this is a preliminary step towards it
15:26 <smyers> I don't think I recommended that we make errata not be content units, right? Just that they already aren't content units, and so we should, as the story says, Refactor errata to be related to repositories.
15:28 <mhrivnak> The current model has definitely proven to be cumbersome. Thinking about what changes could make that better is great. Perhaps a brainstorm session at some point would be productive, to identify some options in a bit more detail.
15:29 <smyers> It strikes me as inherently inappropriate to associate content units with repositories in any way that is separate from the existing RepositoryContentUnit join tabl...er...collection, so justification is warranted for proposing an additional relationship to something that errata are already related to.
15:29 <smyers> For errata, that justification is that they aren't actually content units.
Updated by amacdona@redhat.com over 8 years ago
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
Updated by bmbouter over 5 years ago
- Status changed from NEW to CLOSED - WONTFIX
Pulp 2 is approaching maintenance mode, and this Pulp 2 ticket is not being actively worked on. As such, it is being closed as WONTFIX. Pulp 2 is still accepting contributions though, so if you want to contribute a fix for this ticket, please reopen or comment on it. If you don't have permissions to reopen this ticket, or you want to discuss an issue, please reach out via the developer mailing list.
.