Bug 1707917

Summary:	RFE: Atomic content delivery network update to ensure consistent set of cross-repo rpms.
Product:	Red Hat Update Infrastructure for Cloud Providers	Reporter:	Carlos O'Donell <codonell>
Component:	Operations	Assignee:	Todd Sanders <tsanders>
Status:	NEW ---	QA Contact:	Vratislav Hutsky <vhutsky>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	fweimer, gtanzill
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Carlos O'Donell 2019-05-08 16:58:42 UTC

The Kata Container team at Intel ran into this RHUI issue on Azure:

https://github.com/kata-containers/ci/issues/155#issuecomment-490187454

Where it appears the optional repo was updated ahead of the server repo.

glibc has packages on both repos and they depend upon eachother.

Is it possible for both repos to be out of sync? It seems likely given the example above.

Is the solution is to have an atomic content delivery network update that updates in some kind of "unit" that ensure all of the new component rpms are seen at the same time and are consistent?

As it stands it looks like they may get spurious CI failures every time we update glibc and they need to update via RHUI.

Comment 3 Florian Weimer 2019-05-08 17:53:25 UTC

The lack of atomic multi-repository updates would be an RFE for DNF and its dependencies. Given the age of the optional channels shown in the repository lists, I do not believe this is the issue here.

Comment 4 Carlos O'Donell 2019-05-08 19:35:56 UTC

(In reply to Florian Weimer from comment #3)
> The lack of atomic multi-repository updates would be an RFE for DNF and its
> dependencies. Given the age of the optional channels shown in the repository
> lists, I do not believe this is the issue here.

What could DNF do in this case? Which actions would it take to correct the issue?