[07:52] <ebal[m]> Hello
[07:55]  * ebal[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/JnMMsgLMbxHfZyrsRfQMorxp/message.txt >
[08:52] <meena> ebal[m]: what's the issue on kernel > 5.7?
[08:55] <meena> i'm trying to remember why we made those exceptions for fallocate on XFS rather than just always using dd to begin with
[09:10]  * ebal[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ShEKrtiBPTAtwGBBWmfiRklG/message.txt >
[09:14] <meena> why not truncate, i wonder…
[09:15] <meena> ebal[m]: that's two minutes?!
[09:18] <ebal[m]> test on wsl  ;)  (work laptop)
[13:06] <Odd_Bloke> otubo: Ack, thanks!
[13:09] <Odd_Bloke> [42]: Are you using netplan to configure your Debian system, or you were just referring to the configuration format?
[13:10] <Odd_Bloke> I would expect cloud-init to accept any valid netplan configuration; if you aren't seeing that then a bug would be much appreciated!
[13:16] <Odd_Bloke> ebal[m]: It looks to me from the link to linux-fsdevel on that Bugzilla ticket that you're hitting a kernel bug, not a cloud-init bug; have you raised the issue with your distro's kernel maintainers?
[14:23] <rharper> ebal[m]: meena: re: fallocate on ext4 on 5.8 kernels, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894910
[14:26] <ebal[m]> There is already a couple (or a few) bug reports for this issue (linux/fallocate) and for archlinux also.
[14:26] <ebal[m]> Nevertheless, I wanted to openly discuss it here and exchange ideas or even a workaround.
[14:27] <ebal[m]> personally I am blocked - but it is not important
[14:27] <rharper> dd is the workaround; since this is a regression in the 5.8 kernel, I wouldn't expect any changes to cloud-init here
[14:29] <ebal[m]> it is important to see if there is of any value to suggest that cloud-init can switch to dd as a primary choice instead of fallocate or even provide a flag in cloud-init configuration file so you can choose how the swap partition will be created
[14:29] <ebal[m]> cause in the end, it is a choice to use fallocate against dd ( I guess ).
[14:34] <rharper> I don't see cloud-init switching;  it's a regression in the filesystem in the kernel;    as a workaround for right now, one could use boothook to run a command to move fallocate out of $PATH  (mv /usr/bin/fallocate /root);  when cc_mount runs create_swap with fallocate, this will fail, and cloud-init falls back on dd;
[14:35] <rharper> ebal[m]: I suppose a PR to allow swap: config to take a command would give the user some control over what to use;
[14:39]  * ebal[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/UpoXgazQtXpvigmKMIJDmRWS/message.txt >
[14:40]  * ebal[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/VRvIjGKmKAISzTkTHdxRcyJj/message.txt >
[14:43] <[42]> Odd_Bloke: yes also using netplan to configure it
[14:51] <Odd_Bloke> [42]: And does the configuration work if you manually apply it?
[14:53] <[42]> yes
[14:55] <[42]> this is an example for a machine without public ipv4 https://paste.debian.net/plainh/a1eb40cd
[15:02] <Odd_Bloke> [42]: Are you able to pastebin cloud-init.log from an affected instance?
[15:03] <[42]> i can launch another run in a bit, will need to make sure to set a password to be able to login via console :)
[15:03] <Odd_Bloke> :)
[15:08] <Odd_Bloke> robjo: Are the Python versions that you care about for SUSE still 2.7/3.4 for 12.4 and 3.6 for 15?  (Is cloud-init still(?) being backported to 12.4?)
[15:08] <rharper> [42]: thanks for posting, I don't believe your target os supports netplan, I can reproduce the error with your config when rendering from netplan input to eni;
[15:08] <rharper> https://paste.ubuntu.com/p/wZYpgq498f/
[15:09] <rharper> [42]: do you have what you expect /etc/network/interfaces should look like?   or did you expect netplan to work in which case, netplan detection on debian may need fixing
[15:09] <[42]> i did expect netplan to work
[15:10] <[42]> i'm already using it with netplan manually on some machines
[15:10] <[42]> as in non-cloud-init setups
[15:11] <robjo> Odd_Bloke: yes, I am in the process of switching the build for SLES 12 to Python 3.4
[15:11] <[42]> the error in your paste looks like it's exactly what i saw in the console when i tried
[15:14] <[42]> netplan rendering from the config above results in https://paste.debian.net/plainh/ed1efb52
[15:14] <rharper> [42]: ok, the boot logs will be helpful:  it sounds like you have both ifupdown and netplan installed, cloud-inits default policy for net renderers will try eni first, if found it'll render that;
[15:15] <[42]> that could be the case, i'm using a modified debian cloud-init image which i added netplan.io to
[15:16] <rharper> if you;'re creating your own image, then you can modify /etc/cloud/cloud.cfg and set network: renderers: ['netplan']
[15:17] <rharper> under system_info:
[15:17] <[42]> ok, i'll have a look at that after work, thanks
[15:51] <meena> robjo, Odd_Bloke: does cloud-init even work with 3.4??
[15:54] <powersj> during last years cloud-init summit, as we deprecated python 2 support we agreed to start python 3 support with 3.4
[15:55] <robjo> I have a few more package dependencies to resolve but do not expect any issues on 3.4
[16:19] <Odd_Bloke> meena: Yep, 3.4 is our lowest supported version.
[16:19] <Odd_Bloke> (Else we'd have much better type annotations. :p)
[17:19] <meena> i was wondering…
[17:19] <meena> yah, in libioc we went with 3.6 as the lowest bar
[17:20] <meena> i think… mostly… cuz that's what the lowest bar in FreeBSD was
[19:21] <meena> somebody at redhat created a job for me: https://global-redhat.icims.com/jobs/80986/senior-deployment-engineer---openstack/job