 | NixOS AWS | 64 Members |
| 16 Servers |
| NixOS AWS | 64 Members |
| 16 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Sep 2024 | ||
 Arian | And NixOS obviously doesn't adhere to it.. | 08:39:28 |
| Arian | Like they just need to make a very small change to the API. No need for cloudformation. Why are they making things so complicated | 08:40:25 |
| Arian | They either need to have ImportImage not bail out on NixOS images. Or support ImportSnapshot | 08:40:46 |
| Arian | Oh I have another hack: Pass an AMI to update-image-recipe (and change the version) then throw away the original AMi | 08:51:26 |
| Arian | Then the image builder pipeline can do all the Lifecycle stuff | 08:51:36 |
| Arian | Hmm | 08:51:51 |
| Arian | Nah still kind of hacky | 08:52:22 |
| Arian | If ImportImage would work then we'd only need to import images and set up a Lifecycle policy and nothing else | 08:54:20 |
| Arian | It'd be ideal | 08:54:23 |
| 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 |