2023-12-01 05:09:49 <tomalok> ikke, ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/67 (update alpinelinux.org/cloud with new releases)
2023-12-01 05:12:46 <tomalok> next time i need to bump an EOL forward, i'll do it for more than a day in advance -- the next day in UTC came quicker than I could get 3.15.11 but by the time i ran into problems and fixed them (needed to prune old images because some AWS regions can only hold 30 public AMIs) they were EOL again.  once marked "published" I needed to rebuild those
2023-12-01 05:12:46 <tomalok> as "-r1".
2023-12-01 06:50:30 <ncopa> Good morning! Great job! You have challenges we don’t think of
2023-12-01 06:51:46 <ncopa> there will be a 3.19.0_rc2 later today and 3.19.0 early next week
2023-12-01 15:12:26 <tomalok> ncopa: cool, thanks for the heads-up.
2023-12-01 18:05:04 <tomalok> oh, and ncopa: with regards to the tiny-cloud disabled MR you have out -- looks OK, but if you could find a good place to document that that'd be nifty.
2023-12-01 18:08:29 <ncopa> yeah, we need document alot i think
2023-12-06 17:51:02 <ikke> tomalok: ncopa mentioned a release either tonight or tomorrow morning (CET)
2023-12-06 19:17:59 <tomalok> thanks for the heads up
2023-12-06 19:20:42 <ikke> tomalok: I'm working on the sync script now. Was wondering if I should setup a cronjob, or that it could respond to an mqtt trigger
2023-12-06 19:23:59 <ikke> tomalok: do you have automation that can send an mqtt message (through mosquitto_pub perhaps) when you place images for a release?
2023-12-06 21:11:54 <tomalok> ikke: haven't done mqtt, so don't have triggers.  cronjob would probably be sufficient.  i was considering putting a symlink in the location -- that would be a single atomic operation to signal it's ready to go (and no need to have all the storage duplicated)
2023-12-06 21:12:43 <ikke> yeah, or hardlinks, but  I guess symlinks would work as well
2023-12-07 11:02:00 <ncopa> alpine 3.19 is out
2023-12-07 13:56:38 <ikke> tomalok: I have a script ready to do the synchronization, though I think I'll initially just run it by hand to make sure it works as expected. The idea is to place files / symlinks in /var/lib/image-sync/releases/<release>/<arch>/cloud/. The sync script copies those files from there and then removes them. The idea is that it does not have to keep a local cache of all the files
2023-12-07 13:56:40 <ikke> and prevent it from continuously copying data every time it runs.
2023-12-07 15:14:06 <tomalok> nocpa, ikke: starting the cloud image build, etc.
2023-12-07 15:14:17 <tomalok> nocpa: ^^
2023-12-07 15:14:23 <tomalok> ncopa: ^^
2023-12-07 15:14:44 <ikke> tomalok: 👍
2023-12-07 15:14:49 <ikke> Let me know when you have something ready
2023-12-07 15:15:37 <ncopa> awesome!
2023-12-07 15:33:58 <tomalok> DayJob™ is starting to spin up too, so might be a little while...
2023-12-07 15:34:51 <ikke> o/
2023-12-07 15:49:57 <tomalok> also probably a good idea to do some AWS pruning of old/unused images before attempting to import
2023-12-07 15:59:49 <tomalok> ikke: the current path format being used is "v<version>/cloud/<cloud>/<arch>/<files>" -- it seemed to me to be a logical fit alongside the other stuff -- basically "cloud" would be a sibling to "community", "main", and "releases" -- if i just popped a "v3.19" symlink pointing to the image storage for v3.19 into the /var/lib/image-sync/releases/
2023-12-07 15:59:49 <tomalok> dir, what'd be the result?
2023-12-07 16:01:53 <ikke> tomalok: 1) you cannot write there, 2) atm it only syncs the cloud dir inside each arch dir
2023-12-07 16:20:36 <tomalok> ikke: 1) there = where? 2) storage tree is going to need an overhaul...
2023-12-07 16:21:06 <ikke> directly under /var/lib/image-sync/releases/
2023-12-07 16:23:41 <tomalok> so if we have an 3.19.0 aarch64 image file for azure what would be the expected CDN url for it?
2023-12-07 16:30:55 <ikke> In the structure I setup now, it would be: https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/aarch64/cloud/<file>
2023-12-07 16:33:00 <ikke> ncopa: do you have an opinion?
2023-12-07 16:36:06 <tomalok> current layout https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/v3.19/cloud/azure/aarch64/ -- this is what made sense to me at the time...  someone want alpine v3.19, they want it for the cloud, specifically azure, and they're going to launch an ARM instance.
2023-12-07 16:36:53 <tomalok> variants that match that (tiny cloud, cloudinit, etc.) are in that dir
2023-12-07 16:37:08 <tomalok> (plus any point releases, i.e. 3.19.1)
2023-12-07 16:37:48 <tomalok> but this can all be reorged through configuration :)
2023-12-07 16:39:37 <ikke> my thinking was that all images are currently in the releases/ dir, but wanted a separate dir for security reasons
2023-12-07 16:50:39 <tomalok> my separate dir is just a little closer to the root of the tree  ;)
2023-12-07 16:54:43 <tomalok> also somewhat important -- are you expecting symlinks to be files or dirs of files?  (each image variant is five files -- image, image.sha512, image.asc image.yaml image.yaml.sha512
2023-12-07 16:54:50 <tomalok> )
2023-12-07 16:58:27 <ikke> I've tested with files only, but I think it should work with directories as well
2023-12-07 16:58:33 <ikke> (--copy-links to rsync)
2023-12-07 19:06:47 <thresh> howdy.  I'm looking at (older) AMI images on AWS EC2 and it seems I cant even find a 3.15 one anymore. https://alpinelinux.org/cloud/ pointing to 3.15.11 in e.g. eu-central-1 ami-0dca82c5bf9e61875 is not there.
2023-12-07 19:07:21 <thresh> Also, 538276064493 Owner does not list many (and I believe it used to have lots more)
2023-12-07 19:23:49 <ikke> tomalok: ^
2023-12-07 19:24:02 <ikke> thresh: note that some images have been pruned
2023-12-07 19:24:03 <tomalok> thresh: we've had to do some cleanup.  3.15.11 is EOL, but the last release of each should still be around.
2023-12-07 19:24:55 <tomalok> thresh: what was the variant (tiny/cloudinit, aarch64/x86_64, bios/uefi)?
2023-12-07 19:28:16 <tomalok> ah, dammit i think i see the problem.  it kept 3.15.9 insetad of 3.15.11.  i will get that fixed, but if you need it ASAP i can get you (thresh) an URL to download the right image and self-import.
2023-12-07 20:12:28 <thresh> sorry, was afk.   I don't immediately need it, thanks!
2023-12-07 20:12:36 <thresh> I don't think I see any 3.15, tbh, in eu-central-1
2023-12-07 20:13:06 <thresh> nor earlier releases
2023-12-07 20:15:44 <thresh> $ aws ec2 describe-images --region eu-central-1 --owners 538276064493 | jq '.Images.[].Description' | cut -d' ' -f 1,2,3 | sort | uniq
2023-12-07 20:15:47 <thresh> "Alpine Linux 3.16.8
2023-12-07 20:15:49 <thresh> "Alpine Linux 3.17.6
2023-12-07 20:15:52 <thresh> "Alpine Linux 3.18.5
2023-12-07 20:16:26 <thresh> same for us-east-1 for that matter
2023-12-07 20:50:49 <ncopa> Ikke, tomalok: i like the idea of releases/cloud/arch/files but not really any strong opinion 
2023-12-07 20:51:08 <ikke> it would be releases/arch/cloud/files
2023-12-07 20:51:26 <ikke> or do you want to duplicate the arch folders?
2023-12-07 20:51:38 <ikke> releases/arch vs releases/cloud/arch
2023-12-07 20:53:39 <ncopa> Yeah, that was the idea. We duplicate arch does for repos as well
2023-12-07 20:53:44 <ikke> ok
2023-12-07 20:54:17 <ncopa> arch is currently last element in path
2023-12-07 20:54:22 <tomalok> i would suggest there should be separate subdirs under cloud for each cloud
2023-12-07 20:54:48 <tomalok> releases/cloud/<cloud>/<arch>/<...files...>
2023-12-07 20:55:09 <ncopa> im ok with that
2023-12-07 20:56:24 <ncopa> Actually 
2023-12-07 20:56:25 <tomalok> thresh: that may be an AWS "feature" -- the images have a deprecation date set that hides them -- maybe describe-images has a way around that?
2023-12-07 20:57:16 <ncopa> when thinkin of it. The cloud image file name will need to have the same information 
2023-12-07 20:57:52 <ncopa> eg alpine-nocloud-version-arch something 
2023-12-07 20:57:56 <ikke> Something like this? https://tpaste.us/O8L6
2023-12-07 20:58:10 <tomalok> ncopa: it's currently relying on the dir path to distinguish between clouds
2023-12-07 20:58:22 <ncopa> we don’t really need to duplicate that info 
2023-12-07 20:59:28 <ncopa> we could in theory have it in releases/cloud/files, right?
2023-12-07 20:59:35 <ikke> yes
2023-12-07 21:00:04 <ncopa> we could simplify the other releases as well
2023-12-07 21:00:06 <tomalok> <cloud> currently isn't a part of the image filename -- so there'd be overwrites -- but since we're redoing paths anyways, i could prepend <cloud>_ to the filenames too
2023-12-07 21:00:54 <ikke> I don't mind a dir per cloud either
2023-12-07 21:01:04 <tomalok> i figure it's easier to find stuff that way
2023-12-07 21:01:15 <tomalok> if you're just browsing through
2023-12-07 21:01:23 <ncopa> if you find a downloaded file on your machine but don’t remember which arch it was
2023-12-07 21:01:28 <tomalok> from the downloads page, of course, it'd be much easeir.
2023-12-07 21:01:38 <tomalok> ncopa: yeah, that's occurred to me as well.
2023-12-07 21:01:41 <ikke> right
2023-12-07 21:01:55 <ikke> makes sense to have that info in the file name
2023-12-07 21:02:03 <ncopa> probably would be better to have cloud info in file name
2023-12-07 21:02:17 <ncopa> and try reduce duplicate info
2023-12-07 21:02:42 <ncopa> finding image can be solved other place, eg an index page
2023-12-07 21:03:36 <tomalok> downloading for latest stuff is already sorted on a local branch here for alpinelinux.org/cloud
2023-12-07 21:03:40 <ncopa> only valid reason to add subdues is if we end up with too many files in a dir
2023-12-07 21:03:49 <tomalok> just need to update filenames, paths, and URLs
2023-12-07 21:04:23 <ncopa> tomalok exactly. And with a such page we can create filters etc
2023-12-07 21:04:36 <tomalok> filters already there :)
2023-12-07 21:05:03 <tomalok> even the AWS launch stuff is revamped -- page will be a lot less busy
2023-12-07 21:05:15 <ncopa> so we don’t need to try solve the “easier to find” 
2023-12-07 21:05:32 <ncopa> with for struct
2023-12-07 21:06:09 <ncopa> dir*
2023-12-07 21:07:24 <ncopa> I wonder if we should simplify the other releases as well while at it
2023-12-07 21:08:03 <ikke> ncopa: so what is your proposal?
2023-12-07 21:08:08 <ncopa> i think that not include arch in apk file name was a mistake 
2023-12-07 21:08:45 <ncopa> ikke: to avoid duplication of info
2023-12-07 21:09:22 <ncopa> so: releases/cloud/file
2023-12-07 21:09:38 <ncopa> or maybe even releases/file
2023-12-07 21:09:58 <ncopa> maybe we could dump everything under releases/
2023-12-07 21:11:02 <tomalok> v<version>/releases/cloud/<cloud>_alpine-<release>-<arch>-<variant...>-r<revision> -- path/basename
2023-12-07 21:11:13 <ncopa> one reason to separate in subdue might be to simplify mirror parts ony
2023-12-07 21:11:25 <ncopa> yeah that would work
2023-12-07 21:11:32 <ikke> for syncing, I prefer at least a separate cloud dir
2023-12-07 21:11:55 <ncopa> that is a valid reason 
2023-12-07 21:12:03 <ncopa> a good reason I mean
2023-12-07 21:13:15 <ncopa> maybe we can get rid of the arch directory for the other releases as well
2023-12-07 21:13:56 <ncopa> and add a symlink arch -> .
2023-12-07 21:14:15 <ncopa> for backwards compat
2023-12-07 21:15:18 <thresh> tomalok, oh, TIL, I can see them now with --include-deprecated
2023-12-07 21:15:28 <ikke> Like this: https://tpaste.us/wxEK
2023-12-07 21:15:32 <tomalok> 👍
2023-12-07 21:16:02 <ikke> tomalok: You can write the files in that directory as you see fit
2023-12-07 21:16:26 <ikke> You should be able to write to that dir
2023-12-07 21:16:28 <tomalok> presumably those directories, because we've got 3.16, 3.17, 3.18 too
2023-12-07 21:16:43 <ikke> Yeah, I'll create them now
2023-12-07 21:16:56 <ikke> https://tpaste.us/JRVl
2023-12-07 21:17:38 <ikke> tomalok: oh, just to make it clear, right now I assume it's a drop-off folder, meaning it will remove the files after syncing
2023-12-07 21:17:58 <ikke> that way, I don't need to keep a copy of all files on the sync server either
2023-12-07 21:18:20 <tomalok> i'd put symlinks there, and hope that the symlink is removed and not the file it's pointing to
2023-12-07 21:18:30 <ikke> yeah, it should only remove the symlink
2023-12-07 21:18:42 <ikke> I've already tested it, and the original file is still there
2023-12-07 21:19:41 <tomalok> cool.  okay, lunchtime is long since over, got lots to do...  :/
2023-12-08 03:26:43 <tomalok> ikke ncopa - built/uploaded an edge release to see what what one ends up looking like with the restructured paths/filename -- https://dev.alpinelinux.org/~tomalok/alpine-cloud-images/edge/releases/cloud/
2023-12-08 03:30:42 <tomalok> seems filenames can get long and any trailing .yaml .asc .sha512 might get truncated
2023-12-08 03:31:16 <tomalok> (in the display before the datetime & size)
2023-12-11 15:49:06 <tomalok> ikke: going to do a cloud image release of 3.16 -- symlinks _should_ show up soon, testing our sync process
2023-12-11 15:49:57 <ikke> Ok
2023-12-11 15:51:20 <tomalok> release symlinks are in place
2023-12-11 15:56:11 <ikke> I'll test it in a bit
2023-12-11 16:17:45 <ikke> tomalok: seems to work (synced it locally first)
2023-12-11 16:19:14 <ikke> and the symlinks have been removed
2023-12-11 16:25:07 <tomalok> ikke: so 3.16's not headed out to CDN this round, but otherwise worked ok?
2023-12-11 16:25:15 <ikke> yes
2023-12-11 16:26:06 <tomalok> i can re-release 3.16 and/or put all the rest in place, if you're ready for it
2023-12-11 16:26:31 <ikke> https://tpaste.us/Z59g
2023-12-11 16:26:49 <ikke> I think so
2023-12-11 16:27:18 <tomalok> 👍 shouldn't take long
2023-12-11 16:32:07 <ikke> just fyi, at the moment it will never remove files from the mirror, only add
2023-12-11 16:32:16 <ikke> (cdn)
2023-12-11 16:35:26 <tomalok> i figured that was the case.
2023-12-11 16:36:19 <tomalok> v3.1[6-9] release symlinks in place
2023-12-11 16:43:20 <ikke> running it for 3.16 now
2023-12-11 16:47:30 <ikke> tomalok: http://dl-master.alpinelinux.org/alpine/v3.16/releases/cloud/
2023-12-11 16:48:32 <ikke> I have to go now, I'll do the others later
2023-12-11 16:50:29 <ikke> n/m, I did the others as well
2023-12-11 16:51:23 <tomalok> ikke: thanks!  i'll have a MR for mksite updates in the next day or so -- mostly ready to go, just a matter of time and figuring out what to say about the new cloud image downloads
2023-12-11 16:51:39 <ikke> nod
2023-12-11 17:17:57 <tomalok> ikke: fwiw, looks like v3.19 wasn't done (yet?), but 3.1[6-8] are looking good
2023-12-11 19:01:50 <ikke> tomalok: yeah, 3.18 took longer so I wasn't able to start it
2023-12-11 19:01:57 <ikke> syncing 3.19 now
2023-12-12 01:53:36 <thresh> 3.19 ec2 images work wonderfully.  thanks everyone involved:)
2023-12-12 01:55:37 <minimal> thresh: are you using tiny-cloud or cloud-init?
2023-12-12 02:01:07 <thresh> "alpine-3.19.*-aarch64-uefi-tiny-r*" is my packer regexp..
2023-12-12 02:04:06 <minimal> so tiny-cloud then
2023-12-12 02:07:15 <thresh> I can probably spend some time adapting my images to use cloud-init rather than the rc.local hacks I utilize now
2023-12-12 02:08:12 <thresh> maybe on the christmas week, things will probably be real slow then and I'll be free to spend time tinkering
2023-12-12 02:12:41 <minimal> what sort of "hacks" do you currently use?
2023-12-12 02:13:59 <thresh> I have a one-time script to register the launched VM to configuration management
2023-12-12 02:14:19 <minimal> ah, you could use the "phone-home" module in cloud-init for that
2023-12-12 02:14:21 <thresh> most of the other OSes I bake images for utilize cloud-init per-once functionality
2023-12-12 02:15:33 <minimal> ok. I'm the Alpine cloud-init maintainer and an upstream cloud-init dev so let me know if you hit any issues
2023-12-12 02:16:06 <thresh> neat, will do if I have any
2023-12-12 02:16:56 <minimal> thresh: BTW you mention recently you were using VMWare Fusion on an Arm Mac, correct?
2023-12-12 02:18:06 <thresh> minimal, yep I do, however it's just a VM for quick tests, not something we're using on production (AWS)
2023-12-12 02:18:24 <minimal> recently had the chance to use a friends Arm Mac with Fusion and imported an Alpine disk image I'd created but it wouldn't EFI boot...
2023-12-12 02:18:54 <minimal> it seems to only support NVME rather than (virtio)Scsi but even then it didn't like the disk image I was trying
2023-12-12 02:19:24 <minimal> does it really only support NVME?
2023-12-12 02:24:41 <thresh> the default configuration seems to be nvme, and you can add another disk with choices of "SCSI, SATA, NVME", and IDE is greyed out.  Don't see virtio mentioned anywhere.
2023-12-12 02:25:03 <thresh> I've added a scsi drive, but I don't think I see it anywhere inside a VM, even with virtio-scsi module loaded
2023-12-12 02:26:35 <minimal> thresh: right. When I used an image with a NVME drive it still didn't boot. Was starting to wonder if it was a 512 vs 4K sector size issue but didn't have time to dig any further
2023-12-12 02:27:38 <thresh> seems to be 512 bytes for me if fdisk is to be trusted
2023-12-12 02:27:38 <minimal> was kind of disappointed as I also tried Parallels and it gave a weird EFI error like "unrecognised bootloader" error
2023-12-12 02:27:51 <thresh> I installed 3.17 I think through the iso
2023-12-12 02:27:54 <minimal> thresh: 512/512 or 512/4k?
2023-12-12 02:28:51 <minimal> was a disappointment that my first time trying to get (two) Mac hypervisors going didn't work
2023-12-12 02:30:34 <thresh> blockdev --getss reports 512, --getbsz is 4096
2023-12-12 02:31:19 <thresh> /sys/block/nvme0n1/queue/hw_sector_size is 512
2023-12-12 02:31:40 <thresh> lotsa confusion
2023-12-12 02:32:18 <minimal> so 512/4K then, I'm fairly sure the NVME disk image I build was set for that. Ah well, it'll be a while before I get another chance to test that again
2023-12-12 02:33:27 <minimal> confusion? try /sys/block/nvme0n1/queue/logical_block_size and physical_block_size
2023-12-12 02:33:58 <minimal> its either 512/512, 512/4k or 4k/4k
2023-12-12 02:37:36 <thresh> apparently 512/512
2023-12-12 15:18:39 <tomalok> ikke, ncopa: PR to revamp alpinelinux.org/cloud for image downloads (including non-AWS images) and release 3.19.0 -- https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/71
2023-12-12 15:18:55 <tomalok> s/PR/MR/
2023-12-12 15:19:24 <ikke> Typo in mr
2023-12-12 15:19:40 <ikke> Unless you want to release Alpine 3.9
2023-12-12 15:40:22 <ncopa> nice!
2023-12-12 15:44:05 <tomalok> doh, will fix that
2023-12-12 15:46:31 <tomalok> fix'd
2023-12-12 16:19:14 <ncopa> tomalok: i just pushed an MR to create an ephemeral ip addr if nocloud/alpine datasource is from http, and no ipv4 is configure from before
2023-12-12 16:19:34 <ncopa> not sure how to deal with ipv6
2023-12-12 16:20:11 <ikke> slaac?
2023-12-12 16:20:32 <ncopa> the problem is that how do we know when to enable that?
2023-12-12 16:20:41 <ncopa> right now I check for ipv4 addresses
2023-12-12 16:20:51 <ncopa> but in theory, there could be a working ipv6
2023-12-12 16:21:59 <ikke> check if there is an ULA address configured? (non link-local)
2023-12-12 16:22:01 <ikke> ?
2023-12-12 16:22:23 <ncopa> well, the imds could use a link-local address
2023-12-12 16:22:49 <ncopa> apparently its common for cloud providers to have an imds server on link local address
2023-12-12 16:23:03 <ikke> that makes sense
2023-12-12 16:23:08 <ncopa> it does
2023-12-12 16:23:52 <ncopa> i suppose we could try enabling ephemeral network if imds client fails or something
2023-12-12 16:25:06 <ncopa> https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests/101
2023-12-12 16:26:30 <ikke> I wonder if you need to do anything at all for ipv6
2023-12-12 16:26:43 <ikke> or do you expect there to be cases relying on dhcpv6?
2023-12-12 16:26:58 <ikke> (anything else except bringing the interface up)
2023-12-12 16:27:39 <ncopa> i would expect that slaac woudl be enough
2023-12-12 16:27:52 <ikke> right, that should be enabled by default
2023-12-12 16:28:15 <ncopa> but we need to ip link up?
2023-12-12 16:28:28 <ikke> yes
2023-12-12 16:29:58 <ncopa> i wonder if it would make sense to firs check if we need ephemeral network (eg data source is from http and not from local volume)
2023-12-12 16:30:07 <ncopa> and then try imds
2023-12-12 16:30:37 <ncopa> imds client, and if that fails, then we try configure network
2023-12-12 16:31:13 <ncopa> or something like that
2023-12-12 16:32:11 <ncopa> seems like also cloud-init had issues with ipv6-only: https://github.com/canonical/cloud-init/issues/4540
2023-12-12 16:32:39 <ncopa> ok, I'll continue tomrrow. have a nice evening!
2023-12-12 16:46:12 <tomalok> ncopa: if you use dhcpcd (in all the cloud images) you get IPv6 for free
2023-12-12 16:48:01 <tomalok> ncopa: also IIRC we focused mainly on metadata from a volume, and not so much on metadata from a network source, kinda left that as a future todo
2023-12-13 08:40:04 <ncopa> tomalok: im in the future now, looking at what it would take to get metadata from network source
2023-12-13 08:41:00 <ncopa> i'd rather not depend on dhcpcd on the base media, if possible
2023-12-13 10:36:12 <ncopa> what is the reason for <cloud>-alpine-.... instead of alpine-<cloud>-...?
2023-12-13 11:11:26 <ncopa> I tested the nocloud_alpine image. It works with -smbios type=1,serial='ds=http://10.0.2.2:8000'
2023-12-13 11:14:36 <ncopa> this is awesome
2023-12-13 11:21:12 <ncopa> i wonder if we could add the tiny-cloud-alpine package to nocloud_alpine
2023-12-13 11:21:37 <ncopa> then we'd have #alpine-config user-data support out of the box
2023-12-13 23:52:37 <tomalok> nocopa: cloud first in the name so it's easier to find in a big directory full of images and metadata
2023-12-13 23:55:11 <tomalok> ncopa: ^^ and i think it'd be better if "tiny-cloud-alpine" was implemented as a user-data handler plugin, and not a separate cloud -- if you wanted to do #alpine-config user-data content for nocloud or any other cloud provider, it'd do what you'd expect it to for that content.
2023-12-13 23:58:16 <tomalok> almost everything for #alpine-config is already in the user-data plugin
2023-12-14 07:59:59 <ncopa> I find it harder to find the disk image in a "Download" directory with lots of non-alpine things, but I'll survive :)
2023-12-14 08:03:12 <ncopa> having #alpine-config as user-data only, and not cloud provider might make sense.
2023-12-14 08:05:16 <ncopa> the only reason for having it separate is the check for meta-data/network-interfaces and meta-data/resolv_conf/nameservers before falling back to setting up default interfaces
2023-12-14 08:07:38 <ncopa> but if we could move content of https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/blob/main/lib/tiny-cloud/cloud/alpine/init?ref_type=heads to cloud/nocloud/init, then we're there.
2023-12-14 15:10:49 <tomalok> ncopa what if we temporarily set up ephemeral network (ipv4 & ipv6) for all clouds (and the set_network_interfaces) -- at some point i need to address trying multiple metadata endpoints (again ipv4/ipv6), too.
2023-12-14 15:15:29 <ncopa> i can have a look at that next week. currently the idea was to have a function `want_ephemeral_network` which could detect if temp/ephemeral network is needed or not
2023-12-14 15:15:50 <ncopa> we could set the default to always enable it
2023-12-14 15:16:03 <ncopa> with some check if network is already enabled or something
2023-12-14 15:16:28 <ncopa> i can continue work on that next week. seems like I will be busy with other stuff rest of this week
2023-12-14 18:18:06 <tomalok> ncopa thats fine, i'm überbusy too