Issue #1138
closed
Install applicable errata consumer task does not report kernel packages were updated
Description
When the API is used to have Pulp notify a consumer is updated, the task report that shows the errata details after it completed does not include kernel packages. Since kernel packages are available in errata for the specified consumer, it is expected they will be included in the report. It's not known if the errata actually did install or not, but I suspect they did.
This is likely due to the nature of yum which always installs kernel errata and never "updates" them. This is a special case for errata behavior that we should handle differently.
Updated by bmbouter almost 9 years ago
Possibly tangentially related to this 2.4.1 fixed bug? https://bugzilla.redhat.com/show_bug.cgi?id=1118501
Updated by jortel@redhat.com almost 9 years ago
- Priority changed from Normal to High
- Triaged changed from No to Yes
Updated by semyers about 8 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to semyers
Updated by semyers about 8 years ago
I played some logic-branching code plinko for a little while with this one, but a PR is up now:
https://github.com/pulp/pulp_rpm/pull/820
What I found is that yum keeps a list[0] of "Install-only packages". As the description would imply, these are the packages that yum does not update. Rather, it only ever installs them, installing multiple versions simultaneously if needed. When yum installs or updates these packages, instead of using the "normal" TS_INSTALL or TS_UPDATE transaction state, it reports TS_TRUEINSTALL to differentiate the transaction result from that of a normal package.
Install[1] and update[2] were the only places where I see this short-circuiting to the "addTrueInstall" method happen, and indeed the only place that I would assume that this would happen now that I know it does happen, so those are the only bits of code that needed to be updating. Updating the yum mock that we use to test this code was another matter entirely, but is also included in the linked PR.
So, the problem as reported was that the kernel package wasn't being included in task results, like this one:
...
"result": {
"num_changes": 4,
"reboot": {
"scheduled": false,
"details": {}
},
"succeeded": true,
"details": {
"rpm": {
"details": {
"resolved": [
{
"name": "kernel-tools-libs",
"qname": "kernel-tools-libs-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
},
{
"name": "python-perf",
"qname": "python-perf-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
},
{
"name": "kernel-tools",
"qname": "kernel-tools-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
}
],
"failed": [],
"deps": []
},
"succeeded": true
}
}
},
...
This is what you get now (this time with kernel!):
...
"result": {
"num_changes": 4,
"reboot": {
"scheduled": false,
"details": {}
},
"succeeded": true,
"details": {
"rpm": {
"details": {
"resolved": [
{
"name": "kernel-tools-libs",
"qname": "kernel-tools-libs-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
},
{
"name": "python-perf",
"qname": "python-perf-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
},
{
"name": "kernel",
"qname": "kernel-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
},
{
"name": "kernel-tools",
"qname": "kernel-tools-3.10.0-327.10.1.el7.x86_64",
"epoch": "0",
"version": "3.10.0",
"release": "327.10.1.el7",
"arch": "x86_64",
"repoid": "rhel7"
}
],
"failed": [],
"deps": []
},
"succeeded": true
}
}
},
...
[0]: http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/config.py;h=6bd8d24f709f5b7f45e64ede5e66650ac2701466;hb=d15697ca2b6a74701e900e5f36396dc23a024651#l762
[1]: http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/transactioninfo.py;h=8d47caabbaac91cca1706efd1630fc5fb30aacda;hb=d15697ca2b6a74701e900e5f36396dc23a024651#l453
[2]: http://yum.baseurl.org/gitweb?p=yum.git;a=blob;f=yum/transactioninfo.py;h=8d47caabbaac91cca1706efd1630fc5fb30aacda;hb=d15697ca2b6a74701e900e5f36396dc23a024651#l502
Updated by semyers about 8 years ago
- Status changed from ASSIGNED to POST
- Platform Release set to 2.8.1
Added by semyers about 8 years ago
Updated by semyers about 8 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset 3c9f71c17a6d2cd6896e80a6b738e00f9d61677e.
Updated by semyers about 8 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
Include "TS_TRUEINSTALL" as a valid package state
When installing or updating packages in a consumer, pulp inspects the yum transaction report to decide how to report its actions in the task result. pulp was excluding the "TS_TRUEINSTALL" state, which yum uses as the state of a transaction that updated or installed one of the special packages that can be installed multiple times, such as the kernel.
Including (or rather, not excluding) that state in pulp's transaction reporting lets those packages be included in pulp's task results.
https://pulp.plan.io/issues/1138 fixes #1138