RPM Support

This issue turned out to be a tricky one.
Below are my observations, please, correct me, if I am wrong.

Assumptions:
- the erratum id does not change, when its metadata is updated
- the same erratum can be in different repos (example: RHEL6 and 7)
- any errata metadata can be changed
- if errata metadata is updated there is no guarantee that it will be updated simultaneously in both repos (RHEL6 and 7) or even in the same way.

Right now Pulp stores errata in the collection `units_erratum` and there is no information in database about neither the Pulp repo nor the feed related to each erratum.
If erratum id is the same in different repos but the pkglist name is different, Pulp updates pkglist list by adding a new pkglist to it (this change was introduced by this commit).

So we have one record for each erratum (with erratum_id as a unit_key) even if it is presented in different repositories.
So it looks like it is not safe to update errata metadata, if it could be different for different repositories (RHEL6 and 7).

Any thoughts?

ttereshc wrote:

Assumptions:
- the erratum id does not change, when its metadata is updated
- the same erratum can be in different repos (example: RHEL6 and 7)

I believe these are definitely true.

- any errata metadata can be changed
- if errata metadata is updated there is no guarantee that it will be updated simultaneously in both repos (RHEL6 and 7) or even in the same way.

I don't know if these are true, but I think if assumptions are to be made, it's best to assume that they are. So, any errata metadata can be changed, and it is possible to update only the errata metadata in the rhel6 without making any changes to the rhel7 repo.

Right now Pulp stores errata in the collection `units_erratum` and there is no information in database about neither the Pulp repo nor the feed related to each erratum.
If erratum id is the same in different repos but the pkglist name is different, Pulp updates pkglist list by adding a new pkglist to it (this change was introduced by this commit).

To elaborate on this, because we don't keep track (that I know of) of which repository provides which packages, we don't have a reliable way of choosing which packages to remove from existing package lists. So, if the assumption above is true (any errata metadata can be changed), then that includes the package list. If this assumption is false, and specifically if the packagelist is guaranteed not to change for an errata, then this particular problem goes away.

So we have one record for each erratum (with erratum_id as a unit_key) even if it is presented in different repositories.
So it looks like it is not safe to update errata metadata, if it could be different for different repositories (RHEL6 and 7).

Any thoughts?

Getting solid answers about the two uncertain assumptions is probably the best choice, which I think means we need the answers to these questions before we can know the best way to proceed:

- Can all errata metadata be changed, or only specific fields? If it's only specific fields, which fields can be changed?
- When errata metadata is changed, is it changed for all errata with that ID in all repos where it exists in updateinfo, or are changes potentially made in only a single repo (or subset of repos) containing that errata?

Orthogonally related thought:
This is drastic, but one way forward is to make the errata primary key be a composite key including the errata_id and repo_id. I have some ideas about how to make this work, but would prefer simpler options for a more immediate solution and plan a much-needed (in my opinion) errata refactor for a later release.

On Tuesday, March 22, 2016 7:45:01 PM EDT you wrote:

one way forward is to make the errata primary key be a composite key
including the errata_id and repo_id.

FWIW, this is how I solved the Tag uniqueness problem in pulp_docker.

Answers from jluza:

- Can any errata metadata be changed, or only specific fields? (in case
advisory id has not changed)

They can. I would say almost all fields that are filled by human, are potentially
vulnerable to mistakes so they should be changeable.

Can pkglist also be changed without changing the advisory id?

I suppose it shouldn't happen, but I guess it can.

- The same erratum can be in different repositories (for example, in
RHEL6 and RHEL7).

yes. But it should contain only packages that are in the repository.
Sou you can have multi product advisory, but for RHEL-6 repos, generated
advisories in updateinfo should contain only rhel-6 packages in packagelist.

When errata metadata is changed, is it changed for all errata with the
same id in all repositories?

yes

So for now I am going to overwrite the relevant pkglist (based on its name) and the rest of the errata metadata. Does anyone think it is still not safe to update errata metadata?

New info (at least for me).
Currently the same erratum in different repos (RHEL6 and 7) may have the same name for pkglist (but packages will be different as expected).
That means fix for handling errata from different repositories by concatenating pkglist based on its name does not work :(

Hello Tanya!

I think it might help if we change the uniqueness constraint on Errata to be a compound key of its name and the repo it is part of. Here's an example of how I solved a similar problem with the Tag model in pulp_docker:

https://github.com/pulp/pulp_docker/blob/a902085/plugins/pulp_docker/plugins/models.py#L253

If you follow this approach, it does introduce some other problems however. Now whenever Errata are "copied" between repositories, you actually need to create a new one that is like the old one, but has a different repo_id. I did that for the Tag here:

https://github.com/pulp/pulp_docker/blob/a90208581de1601c02b280175f774dbbca4f251d/plugins/pulp_docker/plugins/importers/importer.py#L260-L266

So my proposal isn't all roses and ponies, but it worked out OK for the Tag. Just a thought!