[FEATURE REQUEST] Migration of repositories between directories

[aplanas]

Is your feature request related to a problem? Please describe.

Add low level routines to support the migration of repositories (including the GPG certificates for those repositories) from the running system to a different part of the filesystem.

Note that a repository contain some metadata (name, alias, URL, etc), but also contain certificates that are used to validate the repository and the packages that are installed from there.

This can be useful in those use cases:

1. System update use case: we booted from a recovery media (PXE boot, or USB), this media contains repositories and certificates that we want to duplicate in the disk of the running system. To do that we can mount the disk in /mnt, and export the repositories that are currently available the the update media into /mnt/etc.

2. System duplication use case: we want to bootstrap a chroot / container / systemd nspawn directory that uses the same repositories and certificates from the running system.

3. System installation case: we generated a reference ISO image that contain the supported repositories and certificates, and we want to install a new system from it. One example can be found in yomi, where we create a subdirectory where is living the new installed system, an we want to add some initial repositories that are cloned form the boot media.

In all three examples the repositories and certificates cannot be stored in pillars, because are unknown until run-time, and are present in a different media, that is the one that we can to migrate from.

TL;DR Sometimes (when booting from a recovery media, for example) we want create repositories, present in the current media, into a mounted device. We should also migrate the GPG keys used for those repositories

Describe the solution you'd like
I see that the solution can be like:

• extend lowpkg module to get the list of keys, delete a key and import a key
• extend pkgrepo state to add a migrated function, that will read the repos from the source, and re-create them in the target directory, including the GPG keys

There is a reference implementation in #58784

[garethgreenaway]

@aplanas Thanks for the report. Can you elaborate a bit more on what some potential use cases for this functionality would be?

[aplanas]

@aplanas Thanks for the report. Can you elaborate a bit more on what some potential use cases for this functionality would be?

Sure! I updated the description and pointed to the reference implementation.

[garethgreenaway]

@aplanas Thanks for the updated description. Can you provide a bit more information about a real situation when someone would use this functionality? Does the installation image that you're referring to contain information such as GPG keys that need to be updated following a re-imaging?

[aplanas]

I extended more the description form the first comment.

@aplanas Thanks for the updated description. Can you provide a bit more information about a real situation when someone would use this functionality?

There are three use cases, one is pointing into a formula that uses this feature. In essence is useful when we want to register repositories in a chroot or in a container, and we cannot store the repository data in a pillar. For example, when we generate images that are outside of salt scope, those images can have different repositories that we do not control, but we want to duplicate then inside the container or inside the chroot.

Does the installation image that you're referring to contain information such as GPG keys that need to be updated following a re-imaging?

A repository contain information about the URL, or name of the repo, but also contain some GPG keys used to certify the repo information and the package origin. Migrate a repo requires a duplication of both of this information.

[aplanas]

Seems that there is a problem here @s0undt3ch? Is there anything that I can do?

[danielrobbins]

@aplanas going to try to get this moving forward. First, I'm going to officially mark the issue as approved for a future release of salt and move it out of needs-triage. Then I need to follow up on the PR. Will assign to me so I don't forget to follow up on this.

[aplanas]

@danielrobbins thanks!!