spoons.technology/scaleway-images

Fork 2

Structure ponderings #4

New issue

Open

opened 2026-01-11 09:49:29 +00:00 by tom · 2 comments

tom commented

2026-01-11 09:49:29 +00:00

Owner

Making this an issue, 'cos it seemed easier than trying to waffle into IRC.

I like the bits, and it's pretty readable (even with a fairly shaky grasp of nix).

Something I found with the way the tiers are structured though, was that I wasn't sure how I might build my own image without needing to also build a new bucket etc.

Not sure if that might be something that's magically solved via having shared terraform state though?

I'm thinking in terms of these blocks:

base nixos image
installing incus
installing forgejo (or any incus app)

The blocks feel like they would get more generic as we move through them - for example, building base images tends to vary quite a bit between providers, installing incus might just need some different variables for stuff like block device names, and installing an app on incus should be the same everywhere.

Would this be a reasonable way to shuffle things:
tier0: generic nixos image at $provider, that can accept a configuration via cloud-init (or something)

would do all the provider specific image building stuff. For example, at scaleway - build with qemu and push via bucket; at upcloud, build via an instance with attached volume. Output is an image/template that we can find via tags.

tier1: instance roles, configured via injected configuration.nix

stuff like incus and the identity services

tier2: applications on top of incus

tier3: application config

Things like access to DNS zones or forgejo organizations

Making this an issue, 'cos it seemed easier than trying to waffle into IRC. I like the bits, and it's pretty readable (even with a fairly shaky grasp of nix). Something I found with the way the tiers are structured though, was that I wasn't sure how I might build my own image without needing to also build a new bucket etc. Not sure if that might be something that's magically solved via having shared terraform state though? I'm thinking in terms of these blocks: - base nixos image - installing incus - installing forgejo (or any incus app) The blocks feel like they would get more generic as we move through them - for example, building base images tends to vary quite a bit between providers, installing incus might just need some different variables for stuff like block device names, and installing an app on incus should be the same everywhere. Would this be a reasonable way to shuffle things: tier0: generic nixos image at $provider, that can accept a configuration via cloud-init (or something) - would do all the provider specific image building stuff. For example, at scaleway - build with qemu and push via bucket; at upcloud, build via an instance with attached volume. Output is an image/template that we can find via tags. tier1: instance roles, configured via injected configuration.nix - stuff like incus and the identity services tier2: applications on top of incus tier3: application config - Things like access to DNS zones or forgejo organizations

tc424 commented

2026-01-11 09:52:35 +00:00

Owner

C&P from IRC, so I can find it again :)

09:50 <@tc424> I think shared tf state would definitely solve some of it, at least
09:51 <@tc424> generating the image actually in the flake like I did for incusos might also help
09:51 <@tc424> then the nixpkgs version is pinned
09:51 <@tc424> I don't know if scaleway can check the hash of an existing S3 object

C&P from IRC, so I can find it again :) ``` 09:50 <@tc424> I think shared tf state would definitely solve some of it, at least 09:51 <@tc424> generating the image actually in the flake like I did for incusos might also help 09:51 <@tc424> then the nixpkgs version is pinned 09:51 <@tc424> I don't know if scaleway can check the hash of an existing S3 object ```

tc424 commented

2026-01-11 09:55:42 +00:00

Owner

09:53 <@theothertom> so in my head, we want an image that reads configuration.nix from user-data
09:54 <@tc424> there seem to be three levels we can use at the moment: the config baked into the image; the config the corpix/nixos provider pushes; and the 
               "settings" bit in the tf resource for final tweaking, maybe for setting hostnames etc

``` 09:53 <@theothertom> so in my head, we want an image that reads configuration.nix from user-data 09:54 <@tc424> there seem to be three levels we can use at the moment: the config baked into the image; the config the corpix/nixos provider pushes; and the "settings" bit in the tf resource for final tweaking, maybe for setting hostnames etc ```

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#4

No description provided.

Rows
Columns