 | NixOS AWS | 64 Members |
| 15 Servers |
| NixOS AWS | 64 Members |
| 15 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Sep 2024 | ||
 Arian | Redacted or Malformed Event | 09:44:03 |
| Arian | So maybe this is something we can ask? "Hey why is ImportImage failing on NixOS images and can you fix it?". Then I think everything slots nicely into AWS Image Builder | 09:45:04 |
| Arian | The error in question by the way: https://discourse.nixos.org/t/fstab-error-while-creating-a-custom-amazon-ec2-ami/6697 | 09:47:23 |
| Arian | And Nixos isn't the only image without /etc/fstab. Any OS following https://uapi-group.org/ doesn't have one needed for boot anymore. | 09:51:53 |
| Arian | The other problem is that ImportImage is sloooooow. Like it takes half an hour to import an image | 16:08:35 |
| Arian | As opposed to 2 minutes with ImportSnapshot | 16:08:50 |
 commiterate | Do we need a base image for a workflow? I thought only recipes needed it and that parent image can be an AMI ID (i.e. not tracked by Image Builder) or an Image ARN (tracked by Image Builder). | 18:07:47 |
| commiterate | Hmm I guess that raises another question of how the workflow's CreateImage step plays with the AWS::ImageBuilder::Image resource. | 18:09:21 |
| commiterate | And I think the lifecycle policy has to be on tags instead of the recipe ARN since we aren't using a recipe. | 18:09:45 |
| commiterate | From what I understand from talking to the PM, Image Builder has 2 ways of building images: a recipe (original) or a workflow (new, launched in December 2023). Workflows are significantly more flexible and seem to only require the SSM Agent (for SSM Run Command) instead of both SSM Agent and AWSTOE. | 18:12:16 |
| commiterate | As for the workflow, it would be a single no-op workflow (e.g. We'd probably make the AMI outside of Cfn and then pass its ID in as a Cfn stack parameter to reference in the workflow for the | 18:25:05 |
| commiterate | But yeah would be really nice if they just make ImportVmImage super general and bring ImportImage up to parity with ImportSnapshot. | 18:25:53 |
| commiterate | * But yeah would be really nice if they just make ImportVmImage super general and bring ImportImage up to parity with ImportSnapshot. With Cfn integration, we can do everything in a single Cfn stack update without any out-of-band nonsense. | 18:26:19 |
| commiterate | I know internally Amazon has need for this as well so I'm trying to expand who they consider potential stakeholders to raise the priority. | 18:27:08 |
| commiterate | On a separate note, Cfn integration for Instance Refresh is already planned for next year though they don't know which quarter they're targeting release yet. | 18:32:40 |
| commiterate | My guess is that it's a single quarter project. | 18:33:16 |
| commiterate | * My guess is that it's a single quarter project having done Cfn integration work before. | 18:33:41 |
| 21 Sep 2024 | ||
| commiterate | * But yeah would be really nice if they just make ImportVmImage super general (support both ImportImage and ImportSnapshot) and bring ImportImage up to parity with ImportSnapshot. With Cfn integration, we can do everything in a single Cfn stack update without any out-of-band nonsense. | 01:40:50 |
 @luna-null:matrix.org joined the room. | 05:44:23 | |
| commiterate | * As for the workflow, it would be a single no-op workflow (e.g. We'd probably make the AMI outside of Cfn and then pass its ID in as a Cfn stack parameter to reference in the workflow for the | 06:03:25 |
| commiterate | * As for the workflow, it would be a single no-op workflow (e.g. We'd probably make the AMI outside of Cfn and then pass its ID in as a Cfn stack parameter to reference in the workflow for the | 06:03:31 |
| Arian | Yes referring to an AMI of course works. But that doesn't solve anything for me. The base image is not managed by the Lifecycle policy iirc | 07:12:24 |
| Arian | So I would still need to write a manual garbage collector | 07:12:35 |
| Arian | In reply to @commiterate:matrix.orgThe recipe argument seems mandatory and its base image argument . The other recipe arguments are optional. Which I assume are then managed by the workflow argument | 07:13:40 |
| Arian | So I agree this is useful. E.g. we can use this for image testing. And in general people might like using image builder to change the base image | 07:14:23 |
| Arian | Just doesn't solve my specific usecase of I want to clean up base images from the NixOS Foundation account after 9 months | 07:14:59 |
| Arian | Anyhow we need to play with this and document what is possible. Please write down what you find in your experiments so that we can add it to the NixOS wiki :) | 07:40:16 |
| commiterate | yeah in its current state we can only really use it for distribution and cleanup of the distributed AMI (not the base). I'll see if I get to experiment with it anytime soon to figure out other weird quirks. I'll likely have to do a placeholder solution at my company where we first only offer Linux + Docker GitLab Runners (use Image Builder with an Amazon Linux base) that are originally intended to be the bootstrap runners to build NixOS images. If Image Builder finally works on the ImportVmImage + Cfn feature request, then we'd be able to expand our supervisor offerings to include NixOS, Mac, Windows, and various hypervisors (e.g. KVM, Hyper-V, Apple Virtualization Framework) to cover both bring-your-own-userspace and bring-your-own-kernel | 19:53:53 |
| commiterate | * yeah in its current state we can only really use it for distribution of the base AMI and cleanup of the distributed AMI (not the base). I'll see if I get to experiment with it anytime soon to figure out other weird quirks. I'll likely have to do a placeholder solution at my company where we first only offer Linux + Docker GitLab Runners (use Image Builder with an Amazon Linux base) that are originally intended to be the bootstrap runners to build NixOS images. If Image Builder finally works on the ImportVmImage + Cfn feature request, then we'd be able to expand our supervisor offerings to include NixOS, Mac, Windows, and various hypervisors (e.g. KVM, Hyper-V, Apple Virtualization Framework) to cover both bring-your-own-userspace and bring-your-own-kernel | 19:55:13 |
| commiterate | * yeah in its current state we can only really use it for distribution of the base AMI and cleanup of the distributed AMI (not the base). I'll see if I get to experiment with it anytime soon to figure out other weird quirks. I'll likely have to do a placeholder solution at my company where we first only offer Linux + Docker GitLab Runners (use Image Builder with an Amazon Linux base) that are originally intended to be the bootstrap runners to build NixOS images. If Image Builder finally works on the ImportVmImage + Cfn feature request, then we'd be able to expand our supervisor offerings to include NixOS, Mac, Windows, Windows + Docker + runhcs, and various hypervisors (e.g. KVM, Hyper-V, Apple Virtualization Framework) to cover both bring-your-own-userspace and bring-your-own-kernel | 20:23:28 |