2023-03-06 19:30:22 <minimal> FYIhttps://aws.amazon.com/about-aws/whats-new/2023/03/amazon-ec2-create-amis-boot-uefi-legacy-bios/
2023-03-06 20:53:21 <tomalok> thanks minimal -- will take a look at that later -- vending a hybrid uefi/bios image has been on the backlog for a while now, hopefully there will be some good info here on how exactly to build such an image
2023-03-06 20:54:34 <tomalok> at the very least this simplifies things when we import/register the AMI
2023-03-06 21:33:40 <minimal> tomalok: Grub supports "hybrid" mode for UEFI and BIOS booting, I've used it in the past for USB sticks
2023-03-06 21:35:28 <minimal> Limini also supprts that but I've not yet tried it with Limine
2023-03-08 08:18:19 <ncopa> hi
2023-03-08 08:18:32 <ncopa> so i have been working on nocloud provider
2023-03-08 08:18:52 <ncopa> i think we need to implement "local-hostname", which is set before network
2023-03-08 08:19:10 <ncopa> so we can use the hostname when requesting ip address from dhcp
2023-03-08 08:19:26 <ncopa> which means that we need to run it in the tiny-cloud-early
2023-03-08 08:20:00 <ncopa> however, -eraly runs before mdev, which means it runs before we have remounted / as rw
2023-03-08 08:20:16 <ncopa> s/-eraly/-early/
2023-03-08 08:21:16 <ncopa> i looked at how cloud-init does it, and it has the stages 'local', 'config' and 'final'
2023-03-08 08:21:40 <ncopa> 'local' corresponds to tiny-cloud-early, but it is run as soon / is remounted rw
2023-03-08 08:22:15 <ncopa> and before network is started
2023-03-08 08:22:55 <ncopa> any ideas how we solve this?
2023-03-08 08:23:24 <ncopa> im thinking that we could move the mdev stuff
2023-03-08 08:24:12 <ncopa> we could move it to mdev-conf, which means we enable it by default for everyone
2023-03-08 09:57:46 <ncopa> what are the EBS /dev/xvd* symlinks needed for?
2023-03-08 11:13:50 <ncopa> I have added support for EBS aliases in mdev-conf: https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/4
2023-03-08 16:41:14 <minimal> ncopa: re "local-hostname", I guess it depends how exactly/how close to cloud-init behaviour you want to be, for cloud-init NoCloud you can either specify "hostname: value" in meta-data file or else specify "hostname: value" in user-data
2023-03-08 16:42:12 <minimal> likewise network config can either be included in meta-data, via "network-interfaces:" section or in network-config file
2023-03-08 16:55:28 <ncopa> well, what we need to do is set hostname before network is up
2023-03-08 16:55:46 <ncopa> so we can pass the hostname to the dhcp client
2023-03-08 16:57:15 <ncopa> i also notice that the expand_root does a remout -o rw
2023-03-08 16:58:01 <ncopa> i think tiny-cloud-early should happen after the /etc/init.d/root has executed and remounted root to rw
2023-03-08 17:00:32 <minimal> ncopa: right, well NoCloud is before network is up, unless you're using NoClout "seedfrom" to pull the config via URLs
2023-03-08 17:00:54 <minimal> speaking from a cloud-init perspective
2023-03-08 17:03:35 <ncopa> https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#permitted-keys only mention "local-hostname"
2023-03-08 17:06:16 <ncopa> tomalok: the MRs that are not "Draft:" can be merged: https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests
2023-03-08 17:10:42 <minimal> ncopa: oh, you're using "ds=" on cmdline, I was thinking mainly in terms of CIDATA ISO/FAT fs
2023-03-08 17:11:12 <minimal> so are you also using "seedfrom" via "ds=" to provide the meta-data and user-data?
2023-03-08 17:30:48 <ncopa> i think it accepts both LABEL=CIDATA and ds= on command line
2023-03-08 18:00:49 <minimal> ncopa: the "cidata"/"CIDATA" labels are automatically search for, I don't think they can be specified on cmdline
2023-03-08 18:02:05 <minimal> ncopa: for what you are working on are you obtaining meta-data/user-data/network-config from a filesystem (ISO/FAT) or from a seed url?
2023-03-08 18:03:25 <ncopa> currently im only adding tests for tiny-cloud, making sure things works as expected when I start refactor things
2023-03-08 18:04:02 <ncopa> the plan is to support filesystem cidata initally and later on seed url
2023-03-08 18:04:25 <ncopa> naturally,  a seed url needs to be fetched after network is configured
2023-03-08 18:05:45 <ncopa> i think we should let tiny-cloud-early execute after root is remounted rw
2023-03-08 18:05:55 <minimal> ncopa: for cloud-init with seed-url a ephimeral network is brought up to contact the seed-url, the "normal" network should then be brought up afterwards
2023-03-08 18:06:17 <ncopa> right
2023-03-08 18:06:18 <minimal> as network config can be obtained via the seed url(s)
2023-03-08 18:06:35 <ncopa> i guess tiny-cloud could support that as well
2023-03-08 18:06:49 <minimal> the same way that things work for e.g. AWS to get to metadata server
2023-03-08 18:06:59 <ncopa> yeah, i figured
2023-03-08 18:08:03 <ncopa> i wonder what is setting up the ephimeral network for alpine aws images currently?
2023-03-08 18:08:10 <minimal> though I seem to remember when I tested seedurls on Alpine with cloud-init I hit a problem with ifupdown-ng's ifup that the attempt to bring up the "proper" network didn't actually happen as ifupdown-ng (ifstate?) seemed to remember the previous settings rather than the modified (by cloud-init) /etc/network/interfaces file
2023-03-08 18:09:52 <ncopa> does not surprise me
2023-03-08 18:10:39 <minimal> it was approx 6 months ago I last tested this stuff with cloud-init
2023-03-08 18:11:13 <minimal> unfortunately ifupdown-ng development in general seems to have "paused"
2023-03-08 18:13:43 <ncopa> ephemeral network could be set up by something else than ifupdown?
2023-03-08 18:14:27 <minimal> from memory cloud-init uses dhclient (certainly for AWS, etc)
2023-03-08 18:15:14 <minimal> that's the only DHCP client that cloud-init officially uses (though udhcpc and dhcpcd work in scenarios where ephemerial DHCP is not needed)
2023-03-08 18:16:39 <ncopa> 169.254.169 is link local address, i guess something configures link-local ipv4 before network is "started"
2023-03-08 18:17:10 <minimal> are you talking about tiny-cloud or cloud-init?
2023-03-08 18:18:22 <ncopa> cloud-init
2023-03-08 18:18:38 <minimal> just looking at the DS code currently
2023-03-08 18:19:11 <ncopa> will continue tomorrow. its late. have a nice evening!
2023-03-08 18:19:55 <minimal> ncopa: yeah, I'll start up a VM which uses seedfrom to refresh my memory
2023-03-09 02:40:39 <tomalok> ncopa: non-draft MRs are merged
2023-03-09 07:55:56 <ncopa> awesome! thanks!
2023-03-09 16:37:55 <Ariadne> 10:10 AM <minimal> it was approx 6 months ago I last tested this stuff with cloud-init
2023-03-09 16:37:55 <Ariadne> 10:11 AM <minimal> unfortunately ifupdown-ng development in general seems to have "paused"
2023-03-09 16:38:11 <Ariadne> not paused intentionally.  present maintainers are just busy with other projects
2023-03-09 16:38:16 <Ariadne> we can add more maintainers :)
2023-03-09 16:59:54 <minimal> Ariadne: understood. It has been almost 1 year since the last release. I'm not a C coder, otherwise I would volunteer
2023-03-10 14:13:25 <minimal> ncopa: FYI I've noticed when using "ds=" on cmdline that, certainly with Grub, I have to enclose the ds value in quotes as otherwise the cmdline passed by Grub to the kernel is truncated at the 1st semicolon
2023-03-24 16:11:52 <ncopa> tomalok: I have added EBS link support to mdev-conf, so we should be able to let tiny-cloud early run after coldplug (kernel modules loaded), after rootfs is remouted rw, but before network
2023-03-24 16:12:30 <ncopa> as I understand it had to run before coldplug so the mdev handler was installed before kernel modules were loaded
2023-03-24 16:25:06 <tomalok> ncopa that was a while ago when that was decided but without looking too close it sounds right.  i think tiny-cloud sets up aliases for xvdX* as well as sdX*, does that also hold true for what's in mdev-conf?
2023-03-24 16:26:10 <ncopa> i think it only sets what nvme-cli shows, so either xvdX* or sdX* but not both
2023-03-24 16:26:14 <tomalok> also was the mdev-conf update in place for 3.17?
2023-03-24 16:26:22 <ncopa> no, not 3.17
2023-03-24 16:26:25 <ncopa> this is for 3.18
2023-03-24 16:26:47 <ncopa> what are those symlinks needed for?
2023-03-24 16:28:46 <tomalok> they may have both been put into place because someone else did it that way and/or non-NVMe disks may have also had both...  or EC2 is/was ambiguous... like i said, been a while.
2023-03-24 16:30:37 <ncopa> logic is here: https://gitlab.alpinelinux.org/alpine/mdev-conf/-/commit/87c664016d5e4ae8131857e3fcab425f6f97bb0b
2023-03-24 16:31:06 <tomalok> at the moment i'm trying to figure out some EC2 ENI eth1+ issues which (i think) are affecting 3.17 -- so after that's solved and backported, we could in theory drop the mdev thing for 3.18+
2023-03-24 16:31:29 <ncopa> do you mind if we only create a single symlink and not both? and if it turns out we need both we add that later?
2023-03-24 16:31:49 <ncopa> iirc the AWS docs only mentions how to create a single symlink
2023-03-24 16:31:56 <tomalok> i don't mind, but we'd need to probably have a release note because behavior change
2023-03-24 16:32:01 <ncopa> yeah
2023-03-24 16:32:12 <ncopa> and maybe bump major version number
2023-03-24 16:32:27 <tomalok> at least minor version
2023-03-24 16:33:14 <ncopa> it is a potentially breaking change. we also move the time where init-early is executed, so i think it justifies a major version number
2023-03-24 16:33:20 <ncopa> i mean, its just a number
2023-03-24 16:33:56 <ncopa> what is the issue with EC2 ENI eth1 issue?
2023-03-24 16:34:07 <ikke> heh
2023-03-24 16:34:55 <tomalok> when i'm attaching an ENI as eth1, it's not routing properly
2023-03-24 16:34:55 <ncopa> i didnt quite understand how that was supposed to work. it look like it tries to configure eth0 (eth*) when it shows up in kernel uevent (cold or hotplug)
2023-03-24 16:35:23 <ncopa> but the code looked broken
2023-03-24 16:36:31 <ncopa> im currently working on tests for init-main, and i just realized it will be complicated with a generic set_fake_meta
2023-03-24 16:36:51 <tomalok> mdev triggers a (potential) rebuild of assemble interfaces and (currently) sets up another udhcpc on eth1, and then goes to look for more IP/IPv6 in imds metadata
2023-03-24 16:37:18 <ncopa> does the mdev trigger actually work?
2023-03-24 16:37:25 <ncopa> is the trigger executed?
2023-03-24 16:37:27 <tomalok> yeah, that works fine
2023-03-24 16:37:58 <tomalok> the problem is once it's done things aren't routing properly and there's two default routes.
2023-03-24 16:38:28 <tomalok> so i'm exploring _not_ running DHCP and just getting imds metadata and setting it up that way
2023-03-24 16:38:40 <tomalok> (no dhcp on eth1)
2023-03-24 16:40:27 <ncopa> two different default routes?
2023-03-24 16:43:47 <tomalok> https://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System using this as a reference to help detangle -- previously i was using the table/rule stuff for associating secondary IPs on the same interface (though I didn't have both "ip rule add from/to"
2023-03-24 16:45:57 <minimal> I thought the xvdX names was because AWS used those originally for disks (back when they used Xen) rather than sdX or vdX
2023-03-24 16:47:31 <tomalok> i'm currently working on  setting up static /etc/network/interfaces.d/eth1 to see if going that route solves the problem -- this may end up reworking (maybe simplifying) the hotplug for ENIs
2023-03-24 16:48:25 <tomalok> the things i do on vacation... :P
2023-03-24 16:49:37 <ncopa> heh
2023-03-24 16:50:13 <ncopa> sounds like pretty advanced networking setup
2023-03-24 16:50:32 <ncopa> how does that actually work from aws? Or, how is it supposed to work?
2023-03-24 16:50:42 <minimal> tomalok: I thought AWS used their own ethernet "tool/package" to set up all networking from the metadata server info? or perhaps all-but-eth0's-main-IP
2023-03-24 16:51:06 <ncopa> you get a second interface, eth1, with a separate subnet and separate default gw?
2023-03-24 16:51:11 <tomalok> really i just want to float static IPv4 & IPv6 between nodes...  
2023-03-24 16:51:44 <ncopa> "float static ip...?"
2023-03-24 16:52:31 <minimal> tomalok: can you do that on AWS? don't you have to rely on the IPs they give the machine on each boot (and then use an elastic IP for "floating")
2023-03-24 16:53:19 <ncopa> multiple default gw may lead to assymetric routing which is why you need a separate routing table which is selected based on source ip
2023-03-24 16:53:26 <tomalok> so i have a docker swarm, and when it's time to refresh each node, in theory i can just launch a new one with all the shiny, and it joins the swarm on the private network.  when it's up, i simply detach the ENI from an old node, and attach it to the new node.  the attaching generates an event that mdev picks up on, and brings up eth1 (per
2023-03-24 16:53:26 <tomalok> ifupdown-ng's configs)
2023-03-24 16:53:57 <tomalok> ncopa: yeah which is why i'm seeing connections only getting half-made
2023-03-24 16:54:40 <ncopa> i create a tool called pingu a dcade ago, that did multi-isp failover (and load-balancing)
2023-03-24 16:54:49 <tomalok> i'm sure that dockerd isn't helping the situation, but for now i'm just tying to establish a connection to SSH port, which should be listening on all interfaces
2023-03-24 16:55:21 <ncopa> so basically, you want to "move" an ip from one host to another?
2023-03-24 16:56:00 <tomalok> yeah, but you have to move detach/attach an AWS reesource so it's not exactly like it can all be done on the hosts
2023-03-24 16:56:40 <ikke> tomalok: does the interface keep the mac address?
2023-03-24 16:56:57 <tomalok> at best the hosts detect that the ENI is gone (and ifdown eth1) and the ENI is there (and ifup eth1) -- there are two other static IPs so, the cluster is fine in the interim
2023-03-24 16:57:10 <tomalok> ikke: good question, haven't checked
2023-03-24 16:57:50 <ncopa> right, so AWS assigns an ip on an iface to host-a. you deassociate it with host-a (it gets removed htoplug style on the host) and then you assign it to other host which gets a hotplug event?
2023-03-24 16:58:10 <tomalok> yep
2023-03-24 16:58:25 <ncopa> and the host is supposed to fetch the metadata for that interface from aws
2023-03-24 16:58:43 <tomalok> that's what "use imds" does in the ifupdown-ng configs
2023-03-24 16:58:50 <ncopa> so you are effectively moving an interface with ip and all from host-a to host-b
2023-03-24 16:59:44 <tomalok> on new host: 0e:64:30:45:c5:05
2023-03-24 17:00:03 <ncopa> yup, so i figured, imds is used to fetch the network config via a link local address
2023-03-24 17:00:13 <tomalok> on old host: 0e:64:30:45:c5:05
2023-03-24 17:00:43 <tomalok> there's some networky things that don't come along on the DHCP ride
2023-03-24 17:00:51 <ncopa> thats pretty cool actually
2023-03-24 17:01:13 <ncopa> its like if you unplug an usb NIC and plug it into another host
2023-03-24 17:01:44 <minimal> tomalok: so how are you updating the interface info in the metadata server?
2023-03-24 17:01:56 <tomalok> udhcpc can't do both ipv4 and ipv6 for example, and then there's secondary IPs that can be on an interface...  and it's also possible to put a whole CIDR on an ENI
2023-03-24 17:02:07 <ncopa> i assume aws handles the metadata
2023-03-24 17:02:14 <ncopa> yeah, udhcpc is pretty limited
2023-03-24 17:03:10 <tomalok> minimal: on the hosts i'm just reading what's there and making it happen (well, whole CIDRs aren't implemented yet) -- altering the ENIs themselves is done via AWS console or API
2023-03-24 17:04:04 <minimal> tomalok: that's why AWS have the amazon-ec2-net-utils on their distro (and used by some other distros) to handle other interfaces and secondary addresses
2023-03-24 17:04:08 <tomalok> AWS also recently made it possible for IPv6-only networking -- and this doesn't work with that either.  if we can sort that out, THEN i think that may justify a major version number bump ;)
2023-03-24 17:05:45 <minimal> yes, and they obviously have a IPv6 address for the metadata server now
2023-03-24 17:05:50 <tomalok> minimal: yes, but it's only really friendly to Amazon Linux...  i did read the code to figure out what it was doing before implementing in tiny-cloud (well, its predecessor) but it has evolved further by then
2023-03-24 17:06:19 <minimal> yes, latest version of that (v2) appears to have been rewritten to use systemd-network lol
2023-03-24 17:06:23 <ncopa> so, for this to work properly, we'd need declarative config and set the configs when the uevent arrives (ala systemd)
2023-03-24 17:06:47 <tomalok> yeah the IPv6 metadata is not a problem...  getting a single DHCP client to be configured to handle either-or-both IPv4 & IPv6 is.
2023-03-24 17:07:02 <ncopa> can dhcpcd do that? I think it may
2023-03-24 17:07:43 <minimal> I believe the AWS "model" is - configure primary IP address via DHCP and then get all other network setting from metadata server (whether immediately, i.e. for secondary address(es)) or via hotplug event for additional interfaces
2023-03-24 17:07:57 <tomalok> that might be a reason to switch the cloud images to use that instead
2023-03-24 17:07:59 <minimal> dhcpcd can do both v4 and v6 in a single daemon
2023-03-24 17:08:32 <ncopa> and i think it also does link-local
2023-03-24 17:09:01 <ncopa> but i don't think it can get an ip form dhcp and then append more addresses to the iface
2023-03-24 17:09:16 <ncopa> i dont think dhcp protocol is designed for that
2023-03-24 17:10:07 <ncopa> so in my mind its either: aws provide your stuff via dhcp, or you get the network config from imds and set it statically
2023-03-24 17:10:24 <ncopa> but getting network config from imds and then set dhcp does not make sense in my mind
2023-03-24 17:11:46 <ncopa> with dhcp you can set "static" ip (a single ip) on server side by connect the ip with mac address
2023-03-24 17:11:54 <tomalok> so there's where ifupdown-ng assists the DHCP client -- after DHCP is done the "use imds" kicks in and fills in the gaps
2023-03-24 17:12:39 <ncopa> "the gaps" here are additional ip addresses and routes?
2023-03-24 17:12:44 <minimal> cloud-init sets up an ephemeral address so it can get to the metadata server in order to retrieve network config
2023-03-24 17:12:55 <minimal> and then downs that epheremal IP afterwards
2023-03-24 17:13:06 <tomalok> ncopa: yep
2023-03-24 17:13:24 <tomalok> eth0: dhcp + imds
2023-03-24 17:13:28 <tomalok> eth1+: imds
2023-03-24 17:13:37 <tomalok> maybe
2023-03-24 17:13:52 <ncopa> minimal: and that epheremal ip is a link-local i assume?
2023-03-24 17:13:59 <minimal> ncopa: those "gaps" are what I was trying to point out to you about tiny-cloud for unsupported cloud providers yesterday
2023-03-24 17:14:35 <ncopa> tomalok: i wonder if we really need dhcp? since we get the network config from imds
2023-03-24 17:15:19 <minimal> ncopa: you can see it handled here: https://github.com/canonical/cloud-init/blob/main/cloudinit/net/ephemeral.py
2023-03-24 17:15:31 <tomalok> we do dhcp on eth0 so we that that interface up to be able to grab the metadata to set up the rest
2023-03-24 17:16:17 <minimal> tomalok: for ephemeral cloud-init is just doing a "ip addr add" rather than using a dhcp client
2023-03-24 17:16:49 <minimal> e.g line 120 of that link I sent
2023-03-24 17:17:38 <minimal> ncopa: cloud-init is using link-local for IPv6 and a specific IP address for IPv4
2023-03-24 17:18:30 <tomalok> minimal: does cloud-init use any sort of dhcp later?
2023-03-24 17:18:50 <ncopa> looks like cloud-init does not use ipv4LL
2023-03-24 17:19:02 <ncopa> unless that is an implementation of ipv4LL
2023-03-24 17:19:40 <minimal> actually I'm confused as there is both EphemeralIPv4Network (line 20) and EphemeralDHCPv4 (line 296) lol
2023-03-24 17:20:00 <ncopa> https://en.wikipedia.org/wiki/Link-local_address#IPv4
2023-03-24 17:20:20 <ncopa> "The simultaneous use of IPv4 addresses of different scope on the same interface, such as configuring link-local addresses as well as globally routable addresses, may lead to confusion and increased complexity.[1]: 1.9  Therefore, hosts search for a DHCP server on the network before assigning link-local addresses."
2023-03-24 17:20:46 <ncopa> i think that is how dhcpcd works, it will fall back to link-local if it fails to get dhcp
2023-03-24 17:20:49 <minimal> ncopa: yes the AWS metadata server's IPv4 address is in the IPv4 local-local address block
2023-03-24 17:21:10 <minimal> 169.254.169.254
2023-03-24 17:21:36 <ncopa> can you reach that metadata after you have got your ipv4 from dhcp? i assume you can, via default route
2023-03-24 17:23:08 <ncopa> tomalok: i might be able to help with the networking bits, but after i have the cloud-config support done and nocloud
2023-03-24 17:23:22 <ncopa> i need the nocloud in for alpine v3.18
2023-03-24 17:24:19 <ncopa> tbh, i dont have that much respect from cloud-init code. I'm not sure its a good reference
2023-03-24 17:24:36 <minimal> ncopa: you understand that nocloud won't help for cloud providers other than AWS/Azure/Oracle/Google that tiny-cloud supports?
2023-03-24 17:24:48 <ncopa> would be interesting to see what they do in amazon linux net utils
2023-03-24 17:25:01 <ncopa> minimal: yes
2023-03-24 17:25:09 <minimal> https://github.com/amazonlinux/amazon-ec2-net-utils
2023-03-24 17:25:43 <tomalok> ncopa: i can create/publish nocloud images -- at the very least a golden image would be pushed to dev.alpinelinux.org/~tomalok/...
2023-03-24 17:26:47 <minimal> ncopa: I don't think there is really any other reference point from a non-EC2-specific perspective
2023-03-24 17:26:49 <tomalok> i do eventually want a set of golden cloud images to be downloadable in all flavors
2023-03-24 17:27:11 <tomalok> need to go afk for a while
2023-03-24 17:29:43 <minimal> tomalok: you're using Packer "natively" on each cloud provider?
2023-03-24 17:30:43 <ncopa> tomalok: yeah, thats why i am working on the cloud-config support in tiny-cloud
2023-03-24 17:31:42 <ncopa> i may also enable tiny-cloud on all alpine iso images so you can do unattended installs of alpine by simply provide a nocloud config on a volume with LABEL=cidata
2023-03-24 17:32:05 <tomalok> ncopa: can build you a 3.17 and/or edge one in short order if you like
2023-03-24 17:32:41 <tomalok> minimal: no longer using cloud providers directly.  images are built for each set of dimensions with QEMU
2023-03-24 17:32:44 <ncopa> i sort of built my own some weeks ago
2023-03-24 17:33:27 <minimal> tomalok: ah, ok, that's good as it would be a pain needing resources in each provider in order to create images
2023-03-24 17:33:28 <ncopa> but i may ask about a nocloud image soonish from edge
2023-03-24 17:33:34 <tomalok> if i can get a stable upload site (for stable downloading) we can start offering different images for a whole lotta clouds without having to import them to those clouds
2023-03-24 17:34:12 <minimal> tomalok: "for a whole lotta clouds"? how would that work without support for various metadata servers?
2023-03-24 17:34:12 <ncopa> we might be able to ship them via dl-cdn.alpinelinux.org at some point
2023-03-24 17:34:19 <tomalok> that was my idea
2023-03-24 17:34:26 <ikke> I was thinking about that as well
2023-03-24 17:34:35 <ncopa> need to go now as well
2023-03-24 17:34:37 <ncopa> its late
2023-03-24 17:34:39 <ikke> o/
2023-03-24 17:35:20 <tomalok> ncopa: https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/v3.17/cloud/aws/aarch64/ 
2023-03-24 17:35:23 <tomalok> for example
2023-03-24 17:35:49 <ikke> Need to think about images for azure as well soon
2023-03-24 17:36:38 <tomalok> if we can figure out where the builder can upload and where alpinelinux.org/cloud can provide downloads we're mostly there.
2023-03-24 17:36:48 <tomalok> gotta run for reals now
2023-03-27 14:30:07 <tomalok> ncopa: https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/edge/cloud/nocloud/ - if there's need for other arch's we can sort out QEMU for that
2023-03-27 14:30:42 <tomalok> ikke: https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/edge/cloud/azure/ - probably "alpha" quality and still some tweaking to do
2023-03-27 14:32:16 <tomalok> edge/3.18 cloud images also switch to using dhcpcd so that one DHCP client handles both/either ipv4/ipv6 as necessary
2023-03-27 15:30:57 <ncopa> nice!
2023-03-27 16:08:38 <clandmeter> Ah azure images nice!
2023-03-27 16:11:08 <tomalok> also oci and gcp
2023-03-27 16:11:39 <tomalok> all need testing (and probably tweaking)
2023-03-27 18:18:33 <ikke> tomalok: nice