2023-02-07 14:53:12 <minimal> ptrc: I just noticed your MR for mkimg but I'm not sure what exactly you are trying to achieve
2023-02-07 14:53:35 <ptrc> generic cloud image with cloud-init
2023-02-07 14:53:54 <ptrc> something like debian/centos genericcloud
2023-02-07 14:56:28 <minimal> ok, but your scripts don't install the cloud-init package...
2023-02-07 14:56:59 <minimal> so generic cloud image without cloud-init (or other alternatives)
2023-02-07 14:57:28 <ptrc> not yet, yes
2023-02-07 14:58:09 <minimal> and with cloud-init you'd also need to decide which optional additional packages to install depending on which cloud-init modules you'd expect people to use
2023-02-07 14:59:02 <minimal> also you're only creating a UEFI image, no BIOS image. Some/many cloud providers still only support BIOS booting
2023-02-07 15:00:10 <minimal> you also have linux-firmware installed, for Cloud use I'd expect that not to be necessary
2023-02-07 15:05:37 <minimal> ptrc: I assume you've seen my own script for creating cloud-init enabled disk images? (it might give you some ideas)
2023-02-07 15:11:49 <ptrc> minimal: i still haven't figured out how to install a BIOS bootloader without booting the whole thing and mounting the boot FAT32 partition 
2023-02-07 15:12:16 <ptrc> i've been looking at https://github.com/dermotbradley/create-alpine-disk-image too
2023-02-07 15:12:28 <minimal> yes that's my script
2023-02-07 15:13:09 <minimal> with my script grub-install runs inside a chroot
2023-02-07 15:14:15 <minimal> where the disk image file is setup on a loop device and then the individual partitions are mounted into the chroot
2023-02-07 15:45:16 <minimal> ptrc: rather than looking at my "raw" scripts you might find it easier to run "./create-alpine-disk-image --cloud generic" and look at the resultant script it creates
2023-02-10 18:03:55 <ncopa> i am doing stable releases to address the openssl vulns
2023-02-13 18:50:25 <ncopa> I think I will try work on tiny-cloud this week
2023-02-13 18:50:57 <ncopa> i will add kyua tests and clean up some bashisms, if that is ok?
2023-02-13 18:51:23 <ncopa> the goal is to make tiny-cloud fully POSIX shell compatible
2023-02-13 18:51:38 <ncopa> and have tests for most of its current stuff
2023-02-13 18:52:24 <ncopa> and I will try get some basic nocloud provider working with basic yaml support
2023-02-13 19:43:29 <ncopa> do you think it would make sense to use nocloud as fallback when CLOUD is unset?
2023-02-13 20:03:22 <ncopa> does it make sense to implement imds for nocloud?
2023-02-13 20:39:13 <ncopa> I'm finding bugs in tiny-cloud
2023-02-13 20:40:22 <ncopa> set -e
2023-02-13 20:40:24 <ncopa> ...
2023-02-13 20:40:28 <minimal> ncopa: imds for nocloud? not sure what you mean? you mean have it talk to a metadata server?
2023-02-13 20:40:43 <ncopa> [ "$op" = show ] && lev=debug
2023-02-13 20:41:23 <ncopa> if $op != show then set -e above will cause the script to exit with failure
2023-02-13 20:41:39 <ncopa> which I suspect is not the intention
2023-02-13 20:42:04 <ncopa> minimal: I'm talking about tiny-cloud imds implementation.
2023-02-13 20:42:54 <ncopa> currently, if you install tiny-cloud and run `imds -h` it will error with "unknown cloud" or similar
2023-02-13 20:42:57 <psykose> that could just be intentional, set -e is not a requirement and writing that style isn't wrong to continue when != :p
2023-02-13 20:43:30 <psykose> though i prefer set -e too
2023-02-13 20:43:56 <minimal> ok, so that's a metadata server then lol. For cloud-init 'NoCloud' as an alternative to loading the YAML files from ISO/fs it supports specifying a base HTTP/HTTPS url from which it will load metadata and user-data files from
2023-02-13 20:44:06 <ncopa> https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/blob/main/lib/mdev/vnic-eth-hotplug#L22
2023-02-13 20:44:49 <ncopa> i suspect its not intentional to exit with error if $op is anything else than "show"
2023-02-13 20:46:09 <minimal> ah, lib/tiny-cloud/nocloud/imds DOES support the cloud-init NOCLOUD method of getting info from HTTP/HTTPS
2023-02-13 20:46:28 <ncopa> minimal: so I configured CLOUD=nocloud, just to test `imds -h`, but then it failed with some error due to missing imds backend for nocloud
2023-02-13 20:46:34 <ncopa> minimal: I think it doesnt
2023-02-13 20:46:56 <minimal> https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/blob/main/lib/tiny-cloud/nocloud/imds#L23
2023-02-13 20:47:18 <ncopa> oh...
2023-02-13 20:47:20 <minimal> "seedfrom" as part of "ds=nocloud" cmdline
2023-02-13 20:47:38 <ncopa> ok, then its probably something else I missed here
2023-02-13 20:48:00 <minimal> documented here: https://canonical-cloud-init.readthedocs-hosted.com/en/latest/reference/datasources/nocloud.html
2023-02-13 20:48:53 <minimal> "With ds=nocloud-net, the seedfrom value must start with http:// or https:// and end with a trailing /."
2023-02-13 20:49:21 <minimal> it then loads "me
2023-02-13 20:49:22 <ncopa> currently I'm just trying to make `imds -h` show help text...
2023-02-13 20:49:54 <minimal> oops "user-data" and "meta-data", and "vendor-data" (from memory) appended to that seedfrom base url
2023-02-13 20:50:20 <minimal> no "network-config" is loaded as obviously the network must be up in order to fetch a http/https url
2023-02-14 05:18:20 <tomalok> ncopa: your testing and tweaking on tiny-cloud is appreciated -- let me know when the MR is stable and ready?
2023-02-14 05:19:02 <tomalok> (it appears to have gone a bit beyond of just adding a test suite, over the course of today)
2023-02-14 13:07:59 <ncopa> tomalok: I think it is ready for merge. I can continue with a new MR
2023-02-14 13:09:13 <ncopa> I am trying to add tests only, make the code testable, and make it posix compatible. No changes in behavior (I think)
2023-02-17 17:05:56 <ikke> Something we asked about before but are still wondering about, can we support providing official Alpine Linux images for Azure
2023-02-17 17:06:24 <ikke> We do have sponsoring from Azure (at least, if we get to extend it) that we can use
2023-02-17 17:11:29 <psykose> is it not possible to just make a single .img/.qcow/whatever that most cloud providers can use instead of this weird specific stuff
2023-02-17 17:12:16 <ikke> afaik, azure requires vhd images
2023-02-17 17:13:51 <ikke> And it would be nice to be able to offer ready to use virtual machines (there are some commercial offerings for Alpine Linux atm)
2023-02-17 17:15:37 <psykose> sounds fine to me
2023-02-17 17:16:10 <ikke> clandmeter already created something in the subscription we have
2023-02-17 17:16:15 <psykose> both in the "sounds sane to do" and the "somebody already does it so there's no point" :D
2023-02-17 17:16:36 <ikke> Well, the latest version is 3.16
2023-02-17 17:16:47 <ikke> Doesn't sound like something that is kept up-to-date
2023-02-17 17:16:52 <psykose> i wonder what we really broke in 3.17
2023-02-17 17:17:00 <psykose> i noticed most people have taken a while to upgrade
2023-02-17 17:17:04 <psykose> or maybe my perception is mistaken
2023-02-17 17:17:09 <ikke> No idea
2023-02-17 17:20:36 <ikke> But I'
2023-02-17 17:21:09 <ikke> I'd like us to be able to offer official images rather than relying on what commercial entities having to offer (and at the same time make it easier for ourselves)
2023-02-17 17:22:27 <psykose> is it easier than doing nothing however
2023-02-17 17:23:35 <ikke> We do need to do something, either host the images in our own subscription or make it available globally
2023-02-17 17:23:51 <minimal> ikke: did you see my post a while ago about Azure's *requirements* for disk images to be added to their Marketplace (even if free)? 32Gb *min* disk image size (from memory) lol
2023-02-17 17:23:53 <psykose> to keep the sponsorship, or?
2023-02-17 17:24:03 <ikke> minimal: yes, I saw it
2023-02-17 17:24:13 <ikke> psykose: no, to start actually using it
2023-02-17 17:24:19 <psykose> ah
2023-02-17 17:24:30 <psykose> well, if there's nothing to use it for anyway, then eh
2023-02-17 17:24:32 <minimal> psykose: yes, with cloud-init there is a default list of all the DataSources and it works out which one ot use
2023-02-17 17:24:43 <ikke> psykose: chicken and egg
2023-02-17 17:24:53 <psykose> minimal: isn't the 32g because it's part of the booted disk (i.e. the size the vm can use to do stuff, write files, ..)
2023-02-17 17:25:28 <psykose> ikke: i don't think so, first you need it for something
2023-02-17 17:25:33 <psykose> this is a requirement not a circle
2023-02-17 17:25:44 <minimal> ikke: I've been wanting to help on official Alpine for all/as many providers as possible........but haven't worked out I can help exactly - who do I ask?
2023-02-17 17:26:20 <ikke> tomalok has been doing most of the work on these things
2023-02-17 17:26:23 <minimal> psykose: cloud-init (and tiny-cloud) AFAIK can grow the disk-image on first boot to the size of the actual disk
2023-02-17 17:26:51 <psykose> maybe they don't offer disks smaller than 32 either :D
2023-02-17 17:27:48 <minimal> having said that the disk image can logically be 32Gb without actually taking up 32Gb in space (i.e. sparse), it just sounds weird lol
2023-02-17 17:29:32 <minimal> ikke: there is my own script BTW (even just as an example)
2023-02-17 17:33:23 <minimal> ikke: is there any chance of me getting some use of the Azure sponsorship?
2023-02-17 17:33:36 <ikke> minimal: I think so
2023-02-17 17:34:14 <ikke> We need to extend before march 3rd, so I'd like that to be confirmed
2023-02-17 17:34:52 <minimal> ikke: that'd be great, I keep holding off setting up various Cloud Provider accounts for testing as I always intend to cram testing into their 1/2 month "free" usage periods lol
2023-02-17 17:35:04 <minimal> 1-2
2023-02-17 17:36:13 <minimal> ikke: BTW did you ever do any more with the "az" packaging you were testing?
2023-02-17 17:37:02 <ikke> minimal: not a lot lately
2023-02-17 17:37:33 <ikke> The problem is that it needs a lot of specific dependencies
2023-02-17 17:37:38 <ikke> not ideal to package
2023-02-17 17:38:01 <ikke> specific as in versions
2023-02-17 17:38:02 <psykose> is it worse than aws-cli-v2
2023-02-17 17:38:11 <ikke> I don't know about aws-cli-v2
2023-02-17 17:38:25 <psykose> requires like 11 specific aws C libraries only they use :D
2023-02-17 17:38:45 <ikke> https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/requirements.py3.Linux.txt
2023-02-17 17:39:06 <ikke> azure-cli split up their tool in dozens of python packages, each for a cloud component
2023-02-17 17:39:28 <psykose> requirements are just ignorable for installing unless they do the runtime check, but yeah that is a mess
2023-02-17 17:40:36 <minimal> BTW there's a new cloud-init release out hopefully next week
2023-02-17 18:02:39 <ncopa> i have been working on tiny-cloud last week
2023-02-17 18:02:46 <ncopa> adding tests mostly
2023-02-17 18:04:33 <ikke> tiny-cloud would replace cloud-init?
2023-02-17 18:04:56 <ncopa> replace a subset of cloud-init is the idea
2023-02-17 18:05:54 <ncopa> i think official azure images would be good
2023-02-17 18:06:45 <ncopa> i think that would be a requirement for alpine support in github actions
2023-02-17 18:07:28 <ikke> I did ask our contact if there is a way we an provide official images
2023-02-17 18:08:45 <ncopa> hum. github actions does not plan to support anything other than ubuntu
2023-02-17 18:09:02 <ikke> It's very centralized
2023-02-17 18:09:17 <ncopa> https://github.com/actions/runner-images#faqs
2023-02-17 18:09:32 <ncopa> they say use docker if you need other distro
2023-02-17 18:09:41 <ikke> I saw they have some generic image that has almost every tool installed?
2023-02-17 18:10:07 <ncopa> i dont know
2023-02-17 18:10:52 <minimal> ikke: Let me dig up the requirements docs for Azure Official (Marketplace) images
2023-02-17 18:11:08 <ikke> https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md
2023-02-17 18:12:37 <ncopa> heh, cached images are ubutnu, debian and alpine
2023-02-17 18:13:07 <minimal> ikke: https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-marketplace-images
2023-02-17 18:13:15 <minimal> that's ONE of the requirements docs
2023-02-17 18:13:49 <ikke> "Security Avoid using LVM." Meh
2023-02-17 18:14:37 <psykose> don't think vm images often use lvm anyway?
2023-02-17 18:14:55 <psykose> security: - Python 2.5 or above (Python 2.6+ is highly recommended) 
2023-02-17 18:14:57 <minimal> psykose: why not?
2023-02-17 18:15:03 <psykose> idk, never seen it
2023-02-17 18:15:06 <ikke> Makes it easier to resize things if you increase disk size
2023-02-17 18:15:09 <psykose> ah
2023-02-17 18:15:39 <minimal> I'd use LVM for separate mountpoints for /home, /var/logs, etc and grow the individual LVs as required
2023-02-17 18:15:46 <ikke> yeah
2023-02-17 18:17:04 <ikke> apparently the issue with lvm is naming colissions
2023-02-17 18:17:08 <ncopa> there is mention of waagent
2023-02-17 18:17:26 <ikke> Azure Linux agent
2023-02-17 18:17:52 <ikke> Does that run on alpine, you mean?
2023-02-17 18:19:09 <ikke> agent seems to be using python
2023-02-17 18:19:19 <ncopa> yup
2023-02-17 18:19:32 <ncopa> ok i need to go
2023-02-17 18:19:41 <ikke> o/
2023-02-17 18:19:46 <minimal> I looked at waagent briefly and decided not to bother with it
2023-02-17 18:23:32 <minimal> related to Azure, in the past I made some local changes to the hvtools Alpine package, I must get around to submitting a MR for that - hvtools contains Hyper-V/Azure specific daemons
2023-02-17 18:24:40 <minimal> as part of that I was considering take over maintainership for hvtools as it hasn't been updated (apart from minor tweaks) since 2017
2023-02-17 18:25:03 <ikke> I don't think ncopa would mind
2023-02-17 18:25:54 <minimal> yeah I just need to finish off one of the shell scripts I added that the daemons expect to be present
2023-02-17 18:26:47 <minimal> the hvtools code is actually in the kernel source, so in theory it should actually be a subpackage of linux-lts
2023-02-17 18:27:10 <psykose> nah
2023-02-18 17:40:25 <tomalok> why is it that whenever i go on vacation, someone mentions me here... ;)
2023-02-18 17:42:10 <minimal> simple solution, never go on vacation ;-)
2023-02-18 17:47:45 <tomalok> current plan with alpine-cloud-images is to have signed "golden images" available for download from us in the format that's native to whatever cloud -- so VHD for AWS and Azure (etc?) and QCOW2 for nocloud -- this would also be the place we store metadata (so we don't have to go use the cloud provider to get that information) -- i have the upload
2023-02-18 17:47:45 <tomalok> of these images and metadata working (to a dev.alpinelinux.org location -- but this should move to somewhere that the CDN can pick up) and there's a couple rounds of actual images built and uploaded there (including 3.17.2, etc.)...  the alpinelinux.org/clouds page already has the code ready (commented out) to offer "download the image".
2023-02-18 17:48:55 <tomalok> iirc, i left off at making the uploaded metadata be authoritative for the build process (cutting out the "ask cloud provider for image details")
2023-02-18 17:49:37 <tomalok> one of these days i should finish that and do a merge.
2023-02-18 17:50:19 <minimal> tomalok: BTW new upstream release of cloud-init is likely next week and I'll update Alpine package (in Edge) shortly afterwards
2023-02-18 17:50:51 <tomalok> thanks for the heads up -- that'd be backported to 3.17, etc. or just edge yet?
2023-02-18 17:51:25 <minimal> am considering whether to backport to 3.17
2023-02-18 17:52:17 <tomalok> LMK, because i can build/release "-r1" images for cloudinit if needed
2023-02-18 17:54:31 <minimal> I added a note to a tiny-cloud Issue/MR where you were asking about AWS IPv6 info giving a pointer to some Amazon articles
2023-02-18 17:56:46 <tomalok> regarding image sizes (reading backwards) our images can be smaller -- based on my experience with OCI the image can be whatever size, but the smallest block volume they support is 75 GiB, so tiny-cloud expands the partition to do that...  i suspect the same holds true for Azure (and GCP), while AWS wins the smallest disk size award.
2023-02-18 18:01:26 <tomalok> minimal: saw that. not sure there was much conversation on that issue -- i think they resolved things?  iirc, the underlying issue is when there's IPv6 only, udhcpc doesn't get everything it needs (but tiny-cloud network bits figure out the IPv6 from metadata and set it up).  udhcpc6 presumably doesn't handle IPv4.  i think the trick is to figure
2023-02-18 18:01:26 <tomalok> out which one to use during boot.
2023-02-18 18:05:17 <minimal> and for a machine with both v4 and v6 run both....or use dhcpcd which can do v4 & v6 in one process
2023-02-18 18:07:54 <minimal> tomalok: part of what I was pointing out is that there is a IPv6 metadata server IP also, obviously for use with IPv6-only instances
2023-02-18 18:11:37 <tomalok> busybox udhcpc/6 are exclusive of each other -- they overwrite each other's results...  and yep, i found the IPv6 metadata IP too.  
2023-02-18 18:53:31 <minimal> tomalok: hmm, with ifupdown-ng it is interesting that where /etc/network/interfaces has both "iface eth0 inet dhcp" and "iface eth0 inet6 dhcp" that only udhcpc is called