Remove sd-base and debian-12-minimal template

[deeplow]

• I have searched for duplicates or related issues

Description

sd-base-bookworm-template as well as debian-12-minimal remain after installing SDW. This leads to unnecessary space (32GB as of April 2024).

Steps to Reproduce

• Setup dev environment
• make dev

Expected Behavior

No base template.

Actual Behavior

sd-base-bookworm-template still present.

Comments

[rocodes]

I have a few thoughts that may be what you had in mind for discussion:

• One issue if we do this is that the template will be re-downloaded whenever we run the updater, until your updater changes are in of course :)
• But even after that, since we don't differentiate between "this is a fresh install provisioning" and "this is a ready-to-go-system that just needs regular updates", the qvm.vm state will run whenever we run any salt states on dom0 unless we make some changes. So suppose we clean up debian minimal and sd-base template after install, and then x months later we decide we need to run dom0 salt states. At that point, which could be once the user has been happily using SDW and/or may have independently downloaded the debian-xx-minimal template to use, our current logic would nuke the user's deb-12-minimal template, then re-download it. I think it's fine to take control of the debian-12-minimal template in our installation process, because we've made clear that the user's installation path should be: Install QubesOS fresh -> install SDW -> do whatever you want after that. But I think nuking a template after some time has passed and users may be using it already would be a bit more hostile.

So I guess I see this as a bigger issue of:

• Do we differentiate "initial provisioning" salt runs from "already installed" salt runs? (which partly conflicts with the declarative uses of Salt in Qubes, eg qvm.vm, vm.present, etc)? If so, how do we do it?

I's a valid point you're making that this isn't a sensible use of disk space. The more I think about it, the more we make progress on our other provisioning goals, the easier it will be to get to a place where we could implement this and still feel confident about system state. But I'm very curious your thoughts :)

[deeplow]

One issue if we do this is that the template will be re-downloaded whenever we run the updater, until your updater changes are in of course :)

Totally. Even with my changes, every time there is a migration it will be downloaded again. I have a few short-term suggestions and some longer-term one.

Short-term:

• we could consider a large conditional jinja block that would only setup the template if it wasn't already present.
• Another (or even complementary) approach is to have partial migrations: when migrating, we state which components are affected and only those parts of the system are targeted. The initial deployment already happens in stages, so I don't think it would be too different.

In the long term (alternative ideas):

• have upstream feature to clone template from repos without a base-template. It would require downloading the base template twice though (some caching would be to assist that). The whole template "bootstraping" could look something like this:

  # Clones a base templateVM from debian-12-minimal
  sd-small-{{ sdvars.distribution }}-template:
    qvm.vm:
      - name: sd-small-{{ sdvars.distribution }}-template
      - clone:
        - from_repository: templates-itl
        - source: debian-12-minimal
        - label: red

• have template provisioning fall outside of the scope of SaltStack (somehow what securedrop-handle-upgrade already does, but in a more systematized way).

At that point, which could be once the user has been happily using SDW and/or may have independently downloaded the debian-xx-minimal template to use, our current logic would nuke the user's deb-12-minimal template, then re-download it.

You are right. However, this introduces its own challenges. When Debian 13 comes along the user may have already downloaded it and played around and when the next workstation version comes along, we'll just use that as the base, thus tainting the workstation. Before then, we should have a more sustainable solution.

Do we differentiate "initial provisioning" salt runs from "already installed" salt runs? (which partly conflicts with the declarative uses of Salt in Qubes, eg qvm.vm, vm.present, etc)? If so, how do we do it?

I see where you're going and it does make sense. I think the issue why this happens is because the sd-template bootstrapping feels a bit more imperative than declarative. We're stating how the template is created, not just that it exists and its composition.

However, as I mentioned above, there will be a time in the future where we need to obtain / use a new version of the default templates and then this won't be considered an initial provisioning yet it will still need to run. So I think we can split the salt provisioning, just not necessarily a long the lines of first and subsequent salt runs.