Actions
Issue #2994
closed
Publish is no-op for repos which contain unit updated by sync of the other repo
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
2.13.2
Platform Release:
OS:
RHEL 7
Triaged:
Yes
Groomed:
No
Sprint Candidate:
Yes
Tags:
Pulp 2
Sprint:
Sprint 29
Quarter:
Description
If unit changes, it's expected that publish of any repo which contains it will be an operational one.
===============
Hi,
recently there was an problem errata problem within the rhel7 rpm/rhel7 optional repositories.
https://access.redhat.com/discussions/3166971
this was fixed by redhat but the fix didn't propagate to my pulp/katello install automatically. I had to force metadata regeneration.
My guess is that the change didn't trigger an update for the updateinfo.xml file because it didn't change packages and it didn't sync any rpms.
old erratum that was not automatically replaced:
# cat 020e0c5ac9eec7fe4d743796f9d42636e00a6765-updateinfo.xml.RHBA-2017:0397
<update status="final" from="release-engineering@redhat.com" version="6" type="bugfix">
<id>RHBA-2017:0397</id>
<issued date="2017-03-02 15:22:54 UTC" />
<title>libvirt bug fix update</title>
<release>0</release>
<rights>Copyright 2017 Red Hat Inc</rights>
<solution>Before applying this update, make sure all previously released errata relevant
to your system have been applied.
For details on how to apply this update, refer to:
https://access.redhat.com/articles/11258</solution>
<severity>None</severity>
<summary>An update for libvirt is now available for Red Hat Enterprise Linux 7.</summary>
<pushcount>6</pushcount>
<description>The libvirt library contains a C API for managing and interacting with the
virtualization capabilities of Linux and other operating systems. In addition,
libvirt provides tools for remote management of virtualized systems.
This update fixes the following bugs:
* Previously, the libvirt code assumed that for any domain disk device found to
be LUKS encrypted, the device would have a libvirt secret associated with the
device to provide the key to unlock the device. As a consequence, when
attempting to access the secret libvirt would crash. This update adds a check to
ensure that not only is there encryption, but there is a secret, before trying
to access the secret object to pass the secret along with the disk. As a result,
it is possible to attach a LUKS encrypted without providing a
libvirt secret to unlock the LUKS disk. This allows the application to
provide the mechanism to unlock the LUKS disk. (BZ# 1411394)
* Previously, libvirt did not provide a method for adding a secret for a virtio-
scsi device during alterations to support a domain master secret for passing the
encrypted secret to qemu. Consequently, it was not possible to hot-plug a
virtio-scsi device using cephx authentication. This update adjusts the algorithm
to add the authentication object with the encrypted secret for qemu to parse. As
a result, libvirt can authenticate a hot-plugged virtio-scsi device. (BZ#
1411398)
Users of libvirt are advised to upgrade to this updated package, which fixes
these bugs. After installing the updated packages, libvirtd will be restarted
automatically.</description>
<updated date="2017-03-02 15:23:06 UTC" />
<references>
<reference href="https://access.redhat.com/errata/RHBA-2017:0397" type="self" id="RHBA-2017:0397" title="RHBA-2017:0397" />
<reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1411394" type="bugzilla" id="1411394" title="libvirtd crashes when attaching raw LUKS volumes" />
<reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1411398" type="bugzilla" id="1411398" title="libvirt no longer generates the cephx auth secret when hot plugging virtio-scsi devices" />
</references>
<pkglist>
<collection short="ITM-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_7_Server_RPMs_x86_64_7Server">
<name>ITM-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_7_Server_RPMs_x86_64_7Server</name>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">e2b171f50761aa1c8e7efd33e6a9e4a8f40d533463b4a8bb194832eceb3175f5</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-client" epoch="0" version="2.0.0" release="10.el7_3.5" arch="i686">
<filename>libvirt-client-2.0.0-10.el7_3.5.i686.rpm</filename>
<sum type="sha256">2cc908e9670cc2fb9c57115bbc03a58bf1dc62582e43e4be8689a3b6a4eca43c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-client" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-client-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f2e3a2ec33cbcbe8603b53c2ea8a9809ef7923bbbd60a1221af298eee59da6be</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">0e541ea3f99661e5aed18f706d5f0e506f30fec78a5a461e615c26117ecbd509</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-config-network" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-config-network-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">133b9a9b0eddba4ec4a65f17372aaf12087452dfafc0447a9d9870094aa18ff3</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-config-nwfilter" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">443342fabd268a5d96c055deae941b96616d84ef4eea0324c296153e7abdb2ea</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-interface" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-interface-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">55e414fe58ddf673bec3caa19970469487889115a3ee142544895d1c6db3d889</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-lxc" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-lxc-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">1419f93b2a705558e94dd06dbe237487da94c6f787de3821d3a63943bb692bbd</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-network" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-network-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f5acf346ead38a00b91e7821eb91f082bcb709fca76d167d0a4523dddc1eb3a6</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-nodedev" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f4015a9045cdabbbd95271a72b90bf619b2b0cdc8ba1a903c318c8bb430ec0fd</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-nwfilter" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">8792f644ab455eba992d9341c5128e4e23c53bf73c9b3b219f79a7e7c3009400</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-qemu" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">1cb078efc1a7755022dadebfdea15637bb34e0a8b6a79445856d1685d5100996</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-secret" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-secret-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">b4826a5b6270e252b34ad5cf593d15be080b756b1ab64b53cc51c9b1a43f506c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-storage" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-storage-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">d0b5d803ee9986c5ba38660ab4f13a4f40d606eeef15968cec005531d668badb</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-kvm" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-kvm-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f2d56cb66c22f4d9f42a170fb01369b3649a3f05bc0793e6084e3dd276e05a18</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-devel" epoch="0" version="2.0.0" release="10.el7_3.5" arch="i686">
<filename>libvirt-devel-2.0.0-10.el7_3.5.i686.rpm</filename>
<sum type="sha256">4c20d67eb6cee9e326d7a65db52965436ab4a5ac441addb40a88fd2dfe489e7c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-devel" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-devel-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">93ac1ad0c325867cb774a0263173fcf542a7faa0456cabf909b4d87bd9cce5c4</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-docs" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-docs-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">e30f5b4abe4ff41cccd9faa2cf1c89c3d82d2e9fbf95c2146e3095370f95cd7d</sum>
</package>
</collection>
</pkglist>
</update>
new erratum after force metadata regeneration:
# cat d10e9238b8961e15622a693ca0f86ab21029d034-updateinfo.xml.RHBA-2017:0397
<update status="final" from="release-engineering@redhat.com" version="6" type="bugfix">
<id>RHBA-2017:0397</id>
<issued date="2017-03-02 15:22:54 UTC" />
<title>libvirt bug fix update</title>
<release>0</release>
<rights>Copyright 2017 Red Hat Inc</rights>
<solution>Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://access.redhat.com/articles/11258</solution>
<severity>None</severity>
<summary>An update for libvirt is now available for Red Hat Enterprise Linux 7.</summary>
<pushcount>6</pushcount>
<description>The libvirt library contains a C API for managing and interacting with the virtualization capabilities of Linux and other operating systems. In addition, libvirt provides tools for remote management of virtualized systems.
This update fixes the following bugs:
* Previously, the libvirt code assumed that for any domain disk device found to be LUKS encrypted, the device would have a libvirt secret associated with the device to provide the key to unlock the device. As a consequence, when attempting to access the secret libvirt would crash. This update adds a check to ensure that not only is there encryption, but there is a secret, before trying to access the secret object to pass the secret along with the disk. As a result, it is possible to attach a LUKS encrypted without providing a
libvirt secret to unlock the LUKS disk. This allows the application to
provide the mechanism to unlock the LUKS disk. (BZ# 1411394)
* Previously, libvirt did not provide a method for adding a secret for a virtio-scsi device during alterations to support a domain master secret for passing the encrypted secret to qemu. Consequently, it was not possible to hot-plug a virtio-scsi device using cephx authentication. This update adjusts the algorithm to add the authentication object with the encrypted secret for qemu to parse. As a result, libvirt can authenticate a hot-plugged virtio-scsi device. (BZ# 1411398)
Users of libvirt are advised to upgrade to this updated package, which fixes these bugs. After installing the updated packages, libvirtd will be restarted automatically.</description>
<updated date="2017-08-28 19:43:17 UTC" />
<references>
<reference href="https://access.redhat.com/errata/RHBA-2017:0397" type="self" id="RHBA-2017:0397" title="RHBA-2017:0397" />
<reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1411394" type="bugzilla" id="1411394" title="libvirtd crashes when attaching raw LUKS volumes" />
<reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1411398" type="bugzilla" id="1411398" title="libvirt no longer generates the cephx auth secret when hot plugging virtio-scsi devices" />
</references>
<pkglist>
<collection short="ITM-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_7_Server_RPMs_x86_64_7Server">
<name>ITM-Red_Hat_Enterprise_Linux_Server-Red_Hat_Enterprise_Linux_7_Server_RPMs_x86_64_7Server</name>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">e2b171f50761aa1c8e7efd33e6a9e4a8f40d533463b4a8bb194832eceb3175f5</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-client" epoch="0" version="2.0.0" release="10.el7_3.5" arch="i686">
<filename>libvirt-client-2.0.0-10.el7_3.5.i686.rpm</filename>
<sum type="sha256">2cc908e9670cc2fb9c57115bbc03a58bf1dc62582e43e4be8689a3b6a4eca43c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-client" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-client-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f2e3a2ec33cbcbe8603b53c2ea8a9809ef7923bbbd60a1221af298eee59da6be</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">0e541ea3f99661e5aed18f706d5f0e506f30fec78a5a461e615c26117ecbd509</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-config-network" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-config-network-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">133b9a9b0eddba4ec4a65f17372aaf12087452dfafc0447a9d9870094aa18ff3</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-config-nwfilter" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">443342fabd268a5d96c055deae941b96616d84ef4eea0324c296153e7abdb2ea</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-interface" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-interface-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">55e414fe58ddf673bec3caa19970469487889115a3ee142544895d1c6db3d889</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-lxc" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-lxc-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">1419f93b2a705558e94dd06dbe237487da94c6f787de3821d3a63943bb692bbd</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-network" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-network-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f5acf346ead38a00b91e7821eb91f082bcb709fca76d167d0a4523dddc1eb3a6</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-nodedev" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f4015a9045cdabbbd95271a72b90bf619b2b0cdc8ba1a903c318c8bb430ec0fd</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-nwfilter" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">8792f644ab455eba992d9341c5128e4e23c53bf73c9b3b219f79a7e7c3009400</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-qemu" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">1cb078efc1a7755022dadebfdea15637bb34e0a8b6a79445856d1685d5100996</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-secret" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-secret-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">b4826a5b6270e252b34ad5cf593d15be080b756b1ab64b53cc51c9b1a43f506c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-driver-storage" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-driver-storage-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">d0b5d803ee9986c5ba38660ab4f13a4f40d606eeef15968cec005531d668badb</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-daemon-kvm" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-daemon-kvm-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">f2d56cb66c22f4d9f42a170fb01369b3649a3f05bc0793e6084e3dd276e05a18</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-devel" epoch="0" version="2.0.0" release="10.el7_3.5" arch="i686">
<filename>libvirt-devel-2.0.0-10.el7_3.5.i686.rpm</filename>
<sum type="sha256">4c20d67eb6cee9e326d7a65db52965436ab4a5ac441addb40a88fd2dfe489e7c</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-devel" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-devel-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">93ac1ad0c325867cb774a0263173fcf542a7faa0456cabf909b4d87bd9cce5c4</sum>
</package>
<package src="libvirt-2.0.0-10.el7_3.5.src.rpm" name="libvirt-docs" epoch="0" version="2.0.0" release="10.el7_3.5" arch="x86_64">
<filename>libvirt-docs-2.0.0-10.el7_3.5.x86_64.rpm</filename>
<sum type="sha256">e30f5b4abe4ff41cccd9faa2cf1c89c3d82d2e9fbf95c2146e3095370f95cd7d</sum>
</package>
</collection>
</pkglist>
</update>
Updated by demter@atix.de over 6 years ago
well other way around -- first one is the old one; 2nd erratum is the new one
Updated by ttereshc over 6 years ago
- Description updated (diff)
Fixed description, as per comment 1.
Updated by jsherril@redhat.com over 6 years ago
To summarize, after an IRC conversation. It seems that if an errata is updated and new errata packages are added (and the updated date is properly updated), pulp will import the errata properly. However if this is the only change to the repository (no rpms are actually added/removed), pulp seems to think that the repo publish does not need to occur via the 'auto_publish' setting on the repository and won't publish those changes. A force_full publish seems to resolve it.
Updated by ttereshc over 6 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
Updated by ttereshc over 6 years ago
- Subject changed from Erratum not updated after upstream change to Publish is no-op for repos which contain unit updated by sync of the other repo
- Description updated (diff)
I was not able to reproduce the issue as described. Publish is operational even if an erratum is the only change in the upstream repo.
However I found out that such issue can happen to the copies of repositories. And it happens not only for errata but for any unit. In case of RPM repo it happens for errata only.
Say, erratum or rpm was updated upstream, a repo with a feed was synced again. The fact that something changed is visible only for the repo which was synced and it's not noticeable for the copies of repo which contain the same unit.
So for repo with a feed - publish will be operational, but for repo copies - publish will be no-op and force_full option should be used.
I'm changing title accordingly, let me know if anyone disagrees.
Updated by ttereshc over 6 years ago
- Status changed from ASSIGNED to POST
Updated by jortel@redhat.com over 6 years ago
- Sprint/Milestone changed from 45 to 46
Updated by ttereshc over 6 years ago
- Status changed from POST to CLOSED - WONTFIX
The proposed fix has substantial impact on sync/publish performance in certain cases. The issue itself (no-op publish in copies of the repo if an erratum update is the only change) will be solved automatically with the next changes to the affected repository copies, or it can be overcome using force_full publish.
Actions
.