 | NixOS AWS | 64 Members |
| 16 Servers |
| NixOS AWS | 64 Members |
| 16 Servers |
| Sender | Message | Time |
|---|---|---|
| 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 |
| 23 Sep 2024 | ||
| 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 things that prefer local image build like NixOS and various hypervisors (e.g. KVM-based options) to cover both bring-your-own-userspace and bring-your-own-kernel | 02:18:46 |
| 24 Sep 2024 | ||
| commiterate | We don't have any NixOS module that polls IMDS's autoscaling/target-lifecycle-status for Terminating and issues a shutdown right? | 22:09:41 |
| commiterate | * We don't have any NixOS module that polls IMDS's autoscaling/target-lifecycle-status for Terminated and issues a shutdown right? | 22:10:02 |
| Arian | Nope. We have something internally at work though. Wanted to generalise it to support systemd-inhibit | 23:06:28 |
| 25 Sep 2024 | ||
| @luna-null:matrix.org changed their display name from luna-null to Autumn. | 06:39:11 | |
| commiterate | Before I bother another EC2 PM or engineer, you know if instance-initiated shutdown (e.g. E.g. If I let a systemd unit have a 1 hour shutdown timeout, will an instance-initiated shutdown get to wait that full hour or does is it still subject to the ~10 min timeout? | 17:55:19 |
| Arian | It will die after 10 minutes | 19:29:47 |
| Arian | If you don't want that you need lifecycle hooks | 19:29:55 |
| Arian | And send heart beats | 19:29:59 |
| commiterate | That's the default case for an EC2-initiated shutdown. What the docs aren't clear about is an instance-initiated shutdown (e.g. we poll IMDS's They also aren't clear about what they do if the instance goes into terminated before the lifecycle hook timeout and we don't call | 20:27:34 |
| commiterate | * That's the default case for an EC2-initiated shutdown. What the docs aren't clear about is an instance-initiated shutdown (e.g. we poll IMDS's They also aren't clear about what they do if the instance goes into terminated before the lifecycle hook timeout and we don't call | 20:27:50 |
| commiterate | * That's the default case for an EC2-initiated shutdown. What the docs aren't clear about is an instance-initiated shutdown (e.g. we poll IMDS's They also aren't clear about what they do if the instance goes into terminated before the lifecycle hook timeout and we don't call | 20:36:50 |
| Arian | I think for instance instanitated shutdown it's just the Lifecycle hook timeout that matters | 21:11:02 |
| Arian | Like systemd doesn't send any signal to the hardware when you call systemctl poweroff. It will only do the poweroff after all the services actually stopped | 21:11:34 |
| Arian | If you have a systemd inhibit or a service that just takes an hour to shut down. There is no way for EC2 to know the machine is shutting down | 21:12:07 |
| Arian | So the machine will be shut down my ec2 after the lifecycle hook timeout | 21:12:45 |
| commiterate | kk. I'm checking with ASG and EC2 just in case but that's what I'm suspecting as well. | 21:52:46 |