Bug 2217455

Summary:	dnf caching in fedora-toolbox images
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	toolbox	Assignee:	Debarshi Ray <debarshir>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	38	CC:	debarshir, go-sig, harrymichal, ogutierr, patrick, sumukher
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jens Petersen 2023-06-26 09:56:54 UTC

(since the fedora-toolbox component is marked inactive: filing under toolbox)

Once a Fedora release is done the main fedora repo basically never changes, only the updates repo.

So if the fedora repo metadata was kept in fedora-toolbox, it seems it would save some time the first time dnf is run inside the toolbox, on the other hand the updates repo should not be cached in the image (specially later after GA).

This is of course a optimization though it could improve the UX of fedora-toolbox.
On the other hand it is not useful for rawhide or branched development...

Reproducible: Always

Comment 1 Debarshi Ray 2023-06-26 11:02:47 UTC

Do you have any estimates on how it might affect the size of the fedora-toolbox images when downloading them over the network?  This might be a trade-off between the first download and the first DNF experiences.

We are making some significant changes to how the fedora-toolbox changes are built as part of https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker  In short, we are looking at building them from a kickstart file instead of a Dockerfile so that they can be integrated into the Fedora composes.  It might be wise to wait for the dust to settle before making any changes to the images.

Comment 2 Debarshi Ray 2023-06-26 11:03:54 UTC

(In reply to Jens Petersen from comment #0)
> (since the fedora-toolbox component is marked inactive: filing under toolbox)

I wonder why is that?  :)

Is it related to the changes for https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker ?  I didn't see anything odd in https://src.fedoraproject.org/container/fedora-toolbox

Comment 3 Jens Petersen 2023-07-04 04:23:06 UTC

(In reply to Debarshi Ray from comment #1)
> Do you have any estimates on how it might affect the size of the
> fedora-toolbox images when downloading them over the network?  This might be
> a trade-off between the first download and the first DNF experiences.

I _think_ it is roughly 72MB, so something to factor in too,
though the image is already so big now that it probably doesn't matter?

> We are making some significant changes to how the fedora-toolbox changes are
> built as part of https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker
> In short, we are looking at building them from a kickstart file instead of a
> Dockerfile so that they can be integrated into the Fedora composes.  It
> might be wise to wait for the dust to settle before making any changes to
> the images.

Agreed

(In reply to Debarshi Ray from comment #2)
> (In reply to Jens Petersen from comment #0)
> > (since the fedora-toolbox component is marked inactive: filing under toolbox)
> 
> I wonder why is that?  :)
> 
> Is it related to the changes for
> https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker ?  I didn't see
> anything odd in https://src.fedoraproject.org/container/fedora-toolbox

I suspect so, but not certain - I only found the related releng tickets/discussion after filing this.

If we get daily refreshes of fedora-toolbox for current releases, that would be a nice plus IMO.