2022-02-01 07:06:14 <ncopa> morning!
2022-02-01 07:07:08 <ncopa> I am interested in a nocloud provider as well. There is a use case for it for the libvirt terrafrom plugin and for things like lima (linux on mac)
2022-02-01 07:07:25 <ncopa> I might be able to help with that
2022-02-01 07:07:50 <ncopa> i mean i have thought about it for a while and have some ideas
2022-02-01 14:34:08 <Xe> ncopa: i've been working on some scripts to help automate this if they would help you, my setup depends on zfs though: https://github.com/Xe/waifud/tree/main/cmd/mkvm
2022-02-01 14:38:38 <ncopa> what I'm trying to do is to slap a cloud-init configs together with a vanilla alpine iso
2022-02-01 15:18:35 <tomalok> ncopa: morning!
2022-02-01 15:22:50 <tomalok> ncopa: i think to add nocloud support to tiny cloud we'd need some _tiny_ way to pick data out of the yaml, some nocloud-specific imds vars/functions in /usr/lib/tiny-cloud/nocloud/imds, and probably a step in tiny-cloud-early init script to mount the volume...
2022-02-01 15:23:22 <tomalok> is there a standard spec for the layout of the yaml, volume label, etc.?
2022-02-01 15:37:06 <ncopa> yes
2022-02-01 15:37:51 <ncopa> I have thought about how to extract the info from yaml in shell, because it is non-trivial
2022-02-01 15:38:39 <ncopa> I first thought to implement something in golang
2022-02-01 15:39:12 <ncopa> there are a handful of cloud-init subset implementations in go
2022-02-01 15:39:43 <ncopa> but the binary size will be huge compared to the current shell implentation
2022-02-01 15:40:05 <tomalok> (nod)
2022-02-01 15:40:34 <ncopa> there are some awk / bash implementations to parse yaml, but they kinda require bash to my understanding and not too beautiful
2022-02-01 15:41:02 <ncopa> I think there is a yq implementation similar to jq, but I think its also written in go and huge
2022-02-01 15:41:47 <ncopa> so I thought, lua is ~300k, what if we do a simple yaml -> json conversion in Lua and pipe that to jq
2022-02-01 15:41:50 <tomalok> what all are you seeking to configure via nocloud?
2022-02-01 15:42:36 <tomalok> jq is not small either
2022-02-01 15:42:40 <ncopa> hostname, user creation, ssh keys and ssh server setup as first step
2022-02-01 15:43:05 <ncopa> exactly, so I ended up with maybe we should use Lua to fish out the info
2022-02-01 15:43:35 <ncopa> the idea is to have some Lua+shell
2022-02-01 15:44:54 <tomalok> of your first step items, hostname, ssh keys (for the "cloud user") would be doable with tiny-cloud, and extraction from yaml for those things might not be too bad
2022-02-01 15:45:18 <tomalok> user creation and ssh config tweaking isn't in tiny-cloud at the moment
2022-02-01 15:45:41 <ncopa> it just need to start ssh server
2022-02-01 15:47:09 <ncopa> I just counted, the full dependency chain for parsing yaml with Lua is ~620k
2022-02-01 15:47:16 <ncopa> which is less than bash
2022-02-01 15:47:33 <ncopa> and less than gawk
2022-02-01 15:48:14 <tomalok> cloud images already have ssh server enabled by default...  and if this is on a non-cloud image, a userdata script can rc-update add/ service start
2022-02-01 15:48:24 <ncopa> ok
2022-02-01 15:48:53 <tomalok> there's not much that can't be accomplished by simply providing a user-data script. ;)
2022-02-01 15:49:08 <ncopa> right, so it only need to support no cloud provider
2022-02-01 15:49:17 <ncopa> I guess user-data script support is needed too
2022-02-01 15:49:46 <tomalok> (nod) tiny-cloud-final saves user-data an executes it if it starts with #!/
2022-02-01 15:50:18 <ncopa> I think it is possible to embed user data scripts in the yaml for no cloud as well
2022-02-01 15:50:53 <tomalok> in a /user-data file, if i'm reading this correctly
2022-02-01 15:51:10 <tomalok>  /user-data /meta-data and optionally /vendor-data
2022-02-01 15:51:23 <ncopa> what I have been thinking for a while, is to rewrite the setup-alpine script, the alpine installer. I think it would be nice if it could take a yaml (or json or whatever) and do an unattended install
2022-02-01 15:51:39 <ncopa> I was thinking to rewrite the entire installer in lua
2022-02-01 15:51:44 <ncopa> (or maybe Go)
2022-02-01 15:52:06 <ncopa> idea was to support nocloud out of the box
2022-02-01 15:52:26 <ncopa> make it possible to set up the disks and everything
2022-02-01 15:52:41 <ncopa> I found at least 3 different implementations of cloud-init in go
2022-02-01 15:53:29 <ncopa> alpine lift, lima (seems to have some sort of cloud-init), and then there was another more general purpose, but it depends on udev/systemd
2022-02-01 15:54:09 <ncopa> so I thought, whatever I do, I better sync with you tomalok, so we can re-use it for cloud images
2022-02-01 15:54:15 <ncopa> that was the thinking so far at least
2022-02-01 15:54:44 <ncopa> the tiny-cloud stuff looks really nice tbh
2022-02-01 15:55:30 <ncopa> tomalok: do you have any experience with libvirt?
2022-02-01 15:55:34 <tomalok> thanks, i tried to organize it for plugability, and consider that we may at some point not be using mdev or openrc
2022-02-01 15:55:37 <minimal> ncopa: an intended *configuration* is what I do on my own physical boxes using cloud-init
2022-02-01 15:55:44 <minimal> oops, unattended
2022-02-01 15:56:04 <ncopa> there is a nice terraform plugin for libvirt, which uses nocloud  provider
2022-02-01 15:56:10 <tomalok> ncopa: nope, haven't played with libvirt
2022-02-01 15:57:32 <tomalok> i would assume that anything that uses nocloud on the virt side would mostly use the yaml files, since there's no IMDS service -- unless the terraform plugin handles the server side that makes the volumes to mount inside the virt?
2022-02-01 15:58:10 <minimal> tomalok: yeah, that's the point of NoCloud - for when there is no metadata server
2022-02-01 15:58:27 <minimal> the Openstack configDrive stuff works in a similar manner
2022-02-01 15:59:58 <minimal> the other method that NoCloud supports is to load meta-data and user-data via a URL, unfortunately it does not support doing so for network-config so (at least currently) only DHCP IPv4 works
2022-02-01 16:02:38 <ncopa> minimal: i tried the "real" cloud init with the libvirt terrafrom, but it didnt work out of the box, and I thought it was a bit bloaty, because I only needed to set the hostname and add ssh keys
2022-02-01 16:03:08 <ncopa> i have a meeting marathon beginning now :-/
2022-02-01 16:03:22 <tomalok> are there docs somewhere detailing the nocloud yaml format for things?
2022-02-01 16:03:39 <tomalok> (i also have to start the DayJob™ now...)
2022-02-01 16:04:03 <ncopa> good question, cloud init docs has some, but it was a bit *much*
2022-02-01 16:04:30 <tomalok> who invented nocloud?  their dox should be authoritative?
2022-02-01 16:05:15 <ncopa> https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
2022-02-01 16:06:23 <ncopa> this is my libvirt terraform experiments:  https://github.com/ncopa/alpine-vm-cluster
2022-02-01 16:09:06 <ncopa> lima-vm has also something for their vms:  https://github.com/lima-vm/alpine-lima
2022-02-01 16:10:02 <ncopa> what I would love is, something very small and simple, for nocloud, and then if something more advanced is needed, redirect users to real cloud-init
2022-02-01 16:10:17 <ncopa> similar to how we use busybox
2022-02-01 16:11:02 <tomalok> (nod) that's the general philosophy behind tiny-cloud...  just need to integrate cloud-init variants into alpine-cloud-images
2022-02-01 16:53:09 <minimal> tomalok: nocloud is a cloud-init thing
2022-02-01 16:54:05 <minimal> agreed - I realise that cloud-init is larger than the likes of tiny-cloud, in part because its written in python, in part because it has a far larger functionality set
2022-02-01 16:54:41 <minimal> I'm doing what I can over time to reduce the Alpine cloud-init dependancies
2022-02-01 16:55:56 <minimal> ncopa: one of the things I'm working on is trying to make cloud-init work with mdev rather than udev - I have some mdev patches to submit shortly for mdev to create some /dev/disk/ softlinks that cloud-init expects
2022-02-01 16:57:54 <minimal> tomalok: this is the NoCloud documentation: https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
2022-02-02 17:20:23 <tomalok> i haven't found any comprehensive documentation about what can/should be contained inside the nocloud yaml -- except for instance-id and local-hostname, really...  is there a standard place to specify the default user's ssh key?
2022-02-02 17:21:33 <tomalok> (or, as this is cloud-init, it probably expects all that to be deep in its user-data instead)
2022-02-02 17:23:00 <ikke> "Basically, user-data is simply user-data and meta-data is a yaml formatted file representing what you’d find in the EC2 metadata service."
2022-02-02 17:23:50 <ikke> I suppose you found that page already
2022-02-02 17:24:42 <tomalok> yeah.  the contents of that metdata isn't 1:1 between EC2's IMDS and what little is documented for nocloud (from what i've been able to find)
2022-02-02 17:26:55 <tomalok> EC2's ssh keys are at meta-data/public-keys/<key-name>=<num>/openssh-key
2022-02-02 17:42:10 <minimal> tomalok: a user's key goes in the user-data YAML
2022-02-02 17:43:57 <minimal> so this would contain something like: "users:", "-default", "ssh_authorized_keys:", followed by the key
2022-02-02 17:44:55 <minimal> you can use "ssh_authorized_keys:" at the "top-level" but then AFAIK it puts the key into all users' authorized_keys file
2022-02-02 17:45:53 <tomalok> tiny-cloud currently only supports one system user
2022-02-02 17:46:04 <tomalok> (defaults to 'alpine')
2022-02-02 17:47:13 <tomalok> and the way most ssh keys provided by metadata is done (well, except GCP), the keys are for that default user
2022-02-02 17:47:18 <minimal> for my cloud-init images I also have a default "alpine" user and, with NoCloud as mentioned above the user-data YAML file inside the ISO/VFAT image contains the above user-data contents
2022-02-02 17:48:00 <minimal> right, but you can also create additional users in the user-data and also specify ssh-keys for them as well
2022-02-02 17:48:46 <tomalok> yeah, that's on the user-data side.  for tiny cloud, that's either a script or plain data payload for something else
2022-02-02 17:49:21 <minimal> the "-default" part of the the "users:" section is obviously used to refer to actions/changes regarding the default user, otherwise you'd specify "- name: testuser" instead
2022-02-02 17:49:58 <tomalok> that's in the userdata or metadata?
2022-02-02 17:50:55 <minimal> user-data
2022-02-02 17:51:25 <minimal> its all documented here: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
2022-02-02 17:52:15 <tomalok> yeah, for tiny cloud the focus is getting the info from meta-data.  any user-data that doesn't begin with #!/ is just along for the ride... ;)
2022-02-02 17:52:28 <minimal> you may perhaps be able to put some key stuff in the meta-data file - I've never tried that
2022-02-02 17:52:41 <tomalok> for parsing of user-data for #cloud-init (or whatnot) they should graduate to using cloud-init ;)
2022-02-02 17:52:47 <minimal> tomalok: ok - but then you're no implementing NoCloud, you implementing something else
2022-02-02 17:53:10 <tomalok> tinynocloud?  ;)
2022-02-02 17:54:54 <tomalok> NopeCloud?  I think TinyCloud can do something NoCloud-ish in order to address some of the things ncopa was talking about yesterday
2022-02-02 17:56:00 <minimal> yeah, RaspiOS for example reads a text file to get Wifi SSID etc. Its been done in various ways by various people. I thought the idea was to be cloud-init compatible rather than invent a new way to do it
2022-02-02 17:56:17 <minimal> e.g. ncopa mentioned some Golang cloud-init compatible projects
2022-02-03 06:49:07 <Ariadne> i mean, i can't tell y'all what to do, but i think that we should be cloud-init compatible
2022-02-05 13:38:26 <ikke> "I am a big fun(sic) of Alpine but I have a problem . When I am trying to launch instance in AWS ec2 with user-data, Alpine does not use script  in user-data. I can not install packages by using user-data  when launching instances."
2022-02-05 16:19:18 <tomalok> what AMI are they using, and what are they using as user-data payload?
2022-02-05 16:20:13 <ikke> It was a review they left
2022-02-05 16:21:02 <tomalok> replyable review?
2022-02-05 16:21:09 <ikke> Nope
2022-02-05 16:21:16 <ikke> It was on the docker hub :D
2022-02-05 16:21:22 <ikke> So not even a relevant location
2022-02-05 16:22:02 <minimal> yeah, no real detail at all
2022-02-05 16:22:40 <tomalok> leave a review answering that one saying "hey go make an issue over here and we'll look into it"?
2022-02-05 16:23:08 <ikke> It's 10 months old, they probably will not look at it
2022-02-05 16:23:48 <tomalok> ah, okay, that's a bit stale.
2022-02-15 19:29:44 <rails> what would be the best way to get an aarch64 qcow2 image, with tiny-cloud in it?
2022-02-15 19:56:07 <tomalok> rails is this for any particular cloud or standalone?
2022-02-15 20:17:52 <rails> tomalok: aarch64.com
2022-02-15 20:18:24 <rails> I need to get an image going so i can start building our metadata server along with it
2022-02-15 20:41:23 <ncopa> rails: maybe with alpine-make-vm-image?
2022-02-15 21:53:00 <tomalok> rails: you could use what we use to build the AWS images (and the others), but not all the way through to the import and publish targets (the "local" target gives you a QCOW image) https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images
2022-02-15 21:54:16 <tomalok> rails: you would probably want to use a --custom configuration to set up aarch64.com specific things
2022-02-15 21:54:28 <rails> mhm, i was looking at that too
2022-02-16 16:56:08 <Ariadne> so i've been making a thing at work: https://github.com/chainguard-dev/apko
2022-02-16 16:56:22 <Ariadne> will package it soon
2022-02-25 17:17:13 <tomalok> minimal: sorted out the issues i was having integrating cloud-init with alpine-cloud-images https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/merge_requests/134 -- aarch64 images were SEGFAULTing at fsck (but x86_64 was ok) -- ensuring e2fsutils was installed was enough to fix it.
2022-02-25 17:18:18 <tomalok> also installed e2fsutils-extra so that resize2fs module could do its stuff too
2022-02-25 17:19:04 <minimal> tomalok: ah, I specifically did not add e2fsprogs/e2fsprogs-extra as dep as some people might be using xfs or some other for rootfs - if you look at the README.Alpine in cloud-init-doc it listed that various packages needed depending on fs type
2022-02-25 17:19:36 <tomalok> and setting datasource_list: ["Ec2"] (or whatever the datasource is for the cloud in question) in cloud.cfg
2022-02-25 17:20:12 <tomalok> it all works, though if there's something else that should be added or config'd by default, lmk
2022-02-25 17:20:18 <minimal> seems I only mentioned the fs packages in the context of resizing: https://git.alpinelinux.org/aports/tree/community/cloud-init/README.Alpine#n225
2022-02-25 17:21:05 <tomalok> what was weird was the segfault only on aarch64.  but all the images should have e2fsutils anyways (as root is ext4, currently)
2022-02-25 17:23:23 <minimal> yeah the dosfstools package is needed for a FAT/VFAT fsck
2022-02-25 17:23:54 <tomalok> that's added when we make UEFI image, for /boot/efi
2022-02-25 17:25:49 <minimal> yeah, maybe have a look at my script for a more realistic set of deps/packages
2022-02-28 09:45:35 <clandmeter> tomalok: have you bumped into https://gitlab.alpinelinux.org/alpine/aports/-/issues/13483 ?
2022-02-28 16:10:32 <tomalok> clandmeter: haven't bumped into it.  typically when i upgrade, i'm rotating instances instead of upgrading and rebooting
2022-02-28 17:31:16 <clandmeter> tomalok: this is not an upgrade, its apk installing sys.
2022-02-28 17:35:48 <minimal> clandmeter: could it be a Busybox cpio issue?
2022-02-28 17:36:04 <tomalok> alpine-cloud-images doesn't rely on the apk triggered run of mkinitfs -- so even if this has been happening, it gets done again later after modules and whatnot are configured
2022-02-28 17:37:16 <clandmeter> minimal: could be, i currently have no proper way to reproduce it
2022-02-28 17:38:02 <minimal> clandmeter: I've not observed this error yet AFAIK in my own script for building sys-based disk images
2022-02-28 17:40:51 <tomalok> taking a look at some edge image builds i did yesterday, there's no cpio errors
2022-02-28 17:42:28 <minimal> minimal: I've search through almost 400 logs of disk images builds going back 7 months and no sign of that error
2022-02-28 17:43:45 <clandmeter> interesting, it happens from time to time for me.
2022-02-28 17:44:07 <clandmeter> maybe it has something to do with io
2022-02-28 17:47:26 <minimal> I'm assuming this is where that error occurs: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/mkinitfs.in#L178
2022-02-28 17:53:21 <clandmeter> i believe so
2022-02-28 17:53:49 <clandmeter> the other 2 instances is a diff usecase, dont think you would get those errors.
2022-02-28 17:58:03 <tomalok> fwiw, i'm also installing syslinux (or grub2 for uefi) with --no-scripts
2022-02-28 18:02:45 <minimal> I'm installed syslinux and Grub (and other packages) as normal, i.e. NOT specifying "--no-scripts", (but inside a chroot)
2022-02-28 18:10:20 <tomalok> my installs are also using --root /path/to/mounted/volume