Rename this repo (again)? #8

Open
opened 2026-01-17 17:13:12 +00:00 by tc424 · 1 comment
Owner

I wonder if this ought to be 'incus-infra' (or 'infra-incus', and rename 'core-infra' to 'infra-core' as well)? The long-term intention is not to be scaleway specific, and the 'base VM' stuff (incusos and nixos) seems to be slowly migrating away to vm-base-images ..

I wonder if this ought to be 'incus-infra' (or 'infra-incus', and rename 'core-infra' to 'infra-core' as well)? The long-term intention is not to be scaleway specific, and the 'base VM' stuff (incusos and nixos) seems to be slowly migrating away to [vm-base-images](https://forge.deathbycomputers.co.uk/spoons.technology/vm-base-images) ..
Owner

Hmm, that seems like it might make sense. I'd thought "scaleway-images" on the assumption that we'd end up with a fork to "fooprovider-images" containing all the variation required to port the build process to something else.
Perhaps though, and especially with nix (where it doesn't seem to be a commonly-templated option), the better approach might be to have a "base" that can be used in several contexts.

Something like this maybe?
base-images repo, creates:

  • docker image
  • raw disk image and/or OVA bundle (suitable for running on home VM hosts)
  • provider-specific images as needed
    Goal of the base is to be minimal, but with easy hooks to make it role-specific - "cloud-init" is what comes to mind, just 'cos of familiarity. Basically anything that would allow applying more config without needing to rebuild would work though.

incus-images (or whatever) repo, creates:

  • provider-specific images, with packages and non-secret config pre-baked
    Goal of these is speeding up startup, at the expense of a longer build. Potentially, this could be done by doing a "the deploy process builds one and makes it a template" thing?
Hmm, that seems like it might make sense. I'd thought "scaleway-images" on the assumption that we'd end up with a fork to "fooprovider-images" containing all the variation required to port the build process to something else. Perhaps though, and especially with nix (where it doesn't seem to be a commonly-templated option), the better approach might be to have a "base" that can be used in several contexts. Something like this maybe? base-images repo, creates: * docker image * raw disk image and/or OVA bundle (suitable for running on home VM hosts) * provider-specific images as needed Goal of the base is to be minimal, but with easy hooks to make it role-specific - "cloud-init" is what comes to mind, just 'cos of familiarity. Basically anything that would allow applying more config without needing to rebuild would work though. incus-images (or whatever) repo, creates: * provider-specific images, with packages and non-secret config pre-baked Goal of these is speeding up startup, at the expense of a longer build. Potentially, this could be done by doing a "the deploy process builds one and makes it a template" thing?
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
spoons.technology/scaleway-images#8
No description provided.