RFC- uyuni support snap

[Kathy0704]

Rendered version

[m-czernek]

When does this happen, and where?
As a user, will I see the list of packages in CLI? In UI?
Will the full list of packages refresh every time I want to select the packages?
Does this happen on the client (minion), or on the server that caches the snap packages?
Do we select only a package name and Uyuni downloads all channels that are available? (stable, beta, candidate, edge, ...) Or are we selecting a channel as well?

Later, you propose the following command to download the snaps:

spacewalk-repo-sync --channel=ubuntu_22.04_snap_stable --type=snap

Does the server already know which packages to download? If so:

• Where and how do we store the list.
• When and how do we ask the user for input to create the list.

[rjmateus]

We cannot have a refresh of the available package list to synchronize. The list refresh must be done asynchronously.
The refresh should be done on the server side. On the minion side, only the packages synchronized to uyuni should be available for installation.
I would say that by default uyuni would only download the stable ones. Users should be able to enable the download of other channels if needed.
Snaps and rpm/deb channels are so different that I think we should have a new command to handle the snap download.
For me it doesn't make sense to add it to the existing spacewalk-repo-sync, which is focusing on traditional packages channels.

[Kathy0704]

When does this happen, and where? As a user, will I see the list of packages in CLI? In UI? Will the full list of packages refresh every time I want to select the packages? Does this happen on the client (minion), or on the server that caches the snap packages? Do we select only a package name and Uyuni downloads all channels that are available? (stable, beta, candidate, edge, ...) Or are we selecting a channel as well?

Later, you propose the following command to download the snaps:

spacewalk-repo-sync --channel=ubuntu_22.04_snap_stable --type=snap

Does the server already know which packages to download? If so:

• Where and how do we store the list.
• When and how do we ask the user for input to create the list.

[Scheduled Task: Cron Job]                      [User Workflow]
+----------------------------------------+       +-----------------------------+
| Every week (or on a schedule):         |       | User opens Uyuni Web UI    |
| - Call Snap search API (a to z)        |       +-----------------------------+
| - Fetch snap_id, publisher_id, etc.    |                   |
| - Store into preloaded metadata table  |                   v
+----------------------------------------+       +-----------------------------+
               |                                      | Create Snap Channel        |
               |                                      +-----------------------------+
               v                                                  |
     +--------------------------------+                           v
     |   Snap Metadata DB (preloaded) |              +-----------------------------+
     +--------------------------------+              | Create Snap Repo            |
               |                                     | - Select Snap package       |
               `-----------------------------------> |   from preloaded DB table   |
                                                     | - Bind repo to a channel    |
                                                     +-----------------------------+
                                                                 |
                                                                 v
                                                     +-----------------------------+
                                                     | Download Files (on demand): |
                                                     | - .snap binary              |
                                                     | - snap-revision.assert      |
                                                     | - account-key.assert        |
                                                     | - snap-declaration.assert   |
                                                     +-----------------------------+
                                                                 |
                                                                 v
                                                     +-----------------------------+
                                                     |     Repo Ready to Serve     |
                                                     +-----------------------------+

[Kathy0704]

Q: When does load the full list of available packages.
, and where?
This occurs on the Uyuni Server as a scheduled background task (e.g., via cron). Periodically (e.g., weekly), the server queries the Snap Store API (using queries from a to z) to fetch metadata for available Snap packages. The collected data (e.g., snap_id, publisher_id, sha3-384) is stored in a preloaded metadata table in the Uyuni database.

Q: As a user, will I see the list of packages in CLI? In UI?
The preloaded Snap package metadata will be visible in the Web UI, during the “Create Snap Repo” workflow. Users will be able to:

Browse the package list via dropdown or search bar.

View package name, publisher, description, etc.

Select desired Snap packages.

also i think CLI should add --snaplist, --add snap packages two options

Q: Will the full list of packages refresh every time I want to select the packages?
No. To avoid performance and API rate issues, the Snap package list is not fetched on demand.

Instead, it's refreshed periodically in the background via a scheduled job (e.g., every week).

This keeps the user experience responsive and avoids repeated API calls to Snapcraft.

Q: Does this happen on the client (minion), or on the server that caches the snap packages?
It happens on the Uyuni Server, which:

Maintains the metadata DB table.

Provides the UI for package selection.

Triggers the download of Snap packages and assertions.
Clients (minions) do not participate in this process — they will consume packages only when instructed via Salt commands.

Q: You propose this command to download snaps:
spacewalk-repo-sync --channel=ubuntu_22.04_snap_stable --type=snap
Does the server already know which packages to download?

Yes — before this command runs:

The user must create a Snap repo and bind it to a Snap channel.

During repo creation, the user selects which Snap packages (and their channels) to manage.

Q: Where and how do we store the list?
The selected packages for each repo are stored in Uyuni's database.
Suggested schema:

Column Description
repo_id Associated repo ID
snap_id Unique Snap ID
snap_name Human-readable name (e.g. htop)
channel Channel (e.g. stable, edge)
publisher_id Publisher fingerprint
Specific revision (optional)
sha3_384 Binary integrity hash

Q: When and how do we ask the user for input to create the list?
The package selection occurs when creating or editing a Snap Repo in the UI.
Users:

Open the "Create Snap Repo" UI.

Choose from the preloaded metadata.

Select Snap(s) and their channel(s).

Bind them to a specific repo and channel.

This setup allows Uyuni to know exactly what to download when spacewalk-repo-sync is invoked.

[m-czernek]

This seems like we want to first call the api.snapcraft.io URL to list all of the packages for user selection (step that happens presumably before we call spacewalk-repo-sync), and then do the same thing again inside of spacewalk-repo-sync?

[m-czernek]

Do we need to focus on Ubuntu 22.04?

Can't I install any snap on any OS that has the snapd service installed?

[rjmateus]

As far as I know, one can install snap on any OS that snapd is available. So we should allow it on uyuni also.

[Kathy0704]

Got it should not focus on the ubuntu 22.04, snap is mainly used by the ubuntu, but another minion whose OS enable to use the snap also can use this feature

[m-czernek]

I'm not sure if I understand why we need this correctly. It seems to me that you're modelling a repo type here, and you want to model one repository per snap channel.

What will this be used for? Why do we need to model repos when we know there's only one repo for snaps, and that's snapcraft.io?

[rjmateus]

According to documentation one can produce snaps from github or even locally and make it available.
Considering that the snap support is so different from repositories, and that they can be generically assigned to any systems, I don't think we should re-use the current channel infrastructure to support snaps.
In my opinion we should create an independent code and database structure to support it, the same way we maid it for configuration channels.
We should have a dedicated snap channel feature in place, where we could manage the data and minion assignement.

[m-czernek]

This RFC itself details the reposync side, i.e. how do we:

• discover snaps
• select snaps for download
• download snaps
• store snaps

I'm missing the description of:

• The API, which will respond to requests from the minion's snap execution.
• The Salt side, which enables server to instruct clients to install/update/remove snaps.
  • For now, we can focus on using Salt directly, i.e. salt <minion-name> snap.install <snap-name> from the server means that the server reaches out to the minion, executes snap install ..., and finally minion uses the Server's new Snap API to install the snap.

We can either keep this in one RFC, of split it into smaller RFCs, that is up to you.

[rjmateus]

It would be great to have the API definition.

[rjmateus]

I think we should first focus on just synchronizing the stable ones only. Other channels could be activated by the users.
At the same time, considering the size and variety of applications that are present in snap, I think it's a good idea not to synchronize all packages by default, and allow users to define which ones should be synchronized.

[rjmateus]

We cannot have a refresh of the available package list to synchronize. The list refresh must be done asynchronously.
The refresh should be done on the server side. On the minion side, only the packages synchronized to uyuni should be available for installation.
I would say that by default uyuni would only download the stable ones. Users should be able to enable the download of other channels if needed.
Snaps and rpm/deb channels are so different that I think we should have a new command to handle the snap download.
For me it doesn't make sense to add it to the existing spacewalk-repo-sync, which is focusing on traditional packages channels.

[rjmateus]

It would be great to have the API definition.

[rjmateus]

As far as I know, one can install snap on any OS that snapd is available. So we should allow it on uyuni also.

[rjmateus]

According to documentation one can produce snaps from github or even locally and make it available.
Considering that the snap support is so different from repositories, and that they can be generically assigned to any systems, I don't think we should re-use the current channel infrastructure to support snaps.
In my opinion we should create an independent code and database structure to support it, the same way we maid it for configuration channels.
We should have a dedicated snap channel feature in place, where we could manage the data and minion assignement.

[rjmateus]

We don't need to maintain consistency with other YUM/DEB repositories, we can have a separated database structure.
Present data/packages in the webUI is a different story, and we can decided if we present them in the same UI table or in a dedicated page for snaps.

[Kathy0704]

Hi Ricardo,

Thanks a lot for your comment. It was very helpful.

Here’s my current idea for creating a local Snap repository in Uyuni:

Users first create a Snap channel.

Then, they bind a repository to that channel, following the traditional Debian/YUM model used in Uyuni.

The repository will present a selectable list of Snap packages (via a search bar or dropdown UI), and unlike deb or yum, it doesn't require a fake URL.

Alternatively, we could simplify the workflow by allowing users to add Snap packages directly to the channel without creating a separate repository.

From a business standpoint, I’m not sure which approach would be more appropriate, so I’d love to hear your thoughts.

I've also included more technical details in the RFC draft—such as how the Snap package list is refreshed and what the database structure looks like. Please take a look whenever you have time.

Sincerely,
Kathy

[wweellddeerr]

Building the catalog using the search endpoint doesn’t seem like a solid approach. Searching from A to Z would cause significant redundancy in the results, since searching for “a” would return all packages containing the character “a” anywhere in the snap name. This means going through all the pages for each letter, with many packages being returned multiple times because they were already found in previous letter searches.

[wweellddeerr]

I’m assuming this change would be applied via a Salt state upon channel subscription. This approach presents both operational challenges and potential security implications.

First, the Uyuni server would need to know its own IP address to include in the Salt state. This becomes problematic if the server doesn’t have a single, stable IP, for example, if it’s behind a NAT or load balancer. Reliably distributing the “correct” IP to all clients is complex, and even if it’s done, a change in the server’s IP would leave minions with outdated /etc/hosts entries that must be manually or otherwise reconfigured.

Beyond operational concerns, the DNS redirection method should also be reviewed for potential security implications, though this is outside my area of expertise.

[wweellddeerr]

I would discard this Method 1 approach unless there is a better alternative for making Uyuni act as the Snap Store for its managed systems without manually configuring DNS to redirect HTTP requests (as described in the Step 2: DNS Configuration subsection).

[wweellddeerr]

This method avoids the security and maintenance risks of Method 1, but its main challenge is adapting Uyuni’s core logic to a fundamentally different package management model. Moving the “source of truth” for package metadata from Uyuni’s database to an external proxy could impact key features such as update applicability checks, patch management, and CLM. Ideally, the RFC should clarify how these will work for snaps, or state if they will not be supported.

The 25-device free limit is also a significant caveat when considering this approach.

[agraul]

Is this the size of the compressed snaps or installed applications? 500GB for 6500 packages seems a bit high.

[agraul]

This is different from current channel management, where whole repositories are mirrored. Have you considered syncing all 6500 snaps instead of only the ones specified by a user?