=== benj_- is now known as benj_
=== cpaelzer__ is now known as cpaelzer
[15:00] <otubo> Anyone interested on taking a quick look at my PR regarding resizing LVM? https://github.com/canonical/cloud-init/pull/721
[15:01] <otubo> smoser: Odd_Bloke
[15:11] <smoser> otubo: looking
=== cpaelzer__ is now known as cpaelzer
[15:41] <smoser> otubo: just hit submit
[15:43] <smoser> meena is much faster than me
[15:44] <otubo> smoser: very interesting insights on how to get it better. Thanks a lot. Will work on that
[15:45] <smoser> otubo: i try to mix in possibly useful comments with my syntax/style complaints.
[15:45] <smoser> the 'is_lvm' though needs to be fixed for sure, and checking whether or not 'lvm' is present.
[15:46] <otubo> smoser: indeed. Agree
[15:50] <minimal> otubo: Hi. Haven't had a chance to have a proper look at your LVM PR yet. From a brief scan it handles native LVM (i.e. on block device) but doesn't handle LVM on LUKS. Did you consider that as well?
[15:52] <otubo> minimal: I realized it was mssing LUKS support yesterday when it was working on my laptop (LUKS) but not working on the VM (no LUKS) :-D So yeah, I'm aware of it, but will probably be another separate PR in the future.
[15:54] <minimal> otubo: Ok. Am currently building LVM and LVM-on-LUKS VMs for other purposes (using cloud-init) so will be able to help out
[15:55] <otubo> minimal: nice! One problem though is that I'm leaving for vacation tomorrow and will probably be back only jan/4th. But yeah, I can ping you
[15:58] <smoser> otubo: enjoy your time off.
[15:58] <otubo> smoser: man, I'm looking forward
[16:03] <meena> smoser, i might have been quicker, but your review was way more useful
=== cpaelzer__ is now known as cpaelzer
[16:36] <smoser> meena: does alpine not have udev ?
[16:41] <minimal> smoser: yes Alpine has udev but its not used by default
[16:41] <minimal> however as the Alpine packager for cloud-init the package has a dependancy on udev
[16:42] <minimal> what's the Alpine issue exactly?
[16:44] <smoser> you commented about lack of udevadm in alpine on otubo's PR
[16:44] <smoser> how does device discovery work without udev ?
[16:44] <smoser> (not that it *can't* work, just what do they use ?)
[16:46] <minimal> smoser: PR 721? I haven't commented on that yet. I see igalic's comment however
[16:47] <smoser> oh. sorry. tab complete fail.
[16:47] <smoser> minimal != meena
[16:47] <minimal> normally on Alpine mdev is used. However when I packaged cloud-init for Alpine I ensured that the Alpine package depends on udev rather than mdev as I saw that both the persistent net device naming and the disk setup modules in cloud-init expect udev
[16:48] <minimal> I'm the Alpine cloud-init package manintainer and also the person who upstreamed Alpine support in cloud-init :-)
[16:48] <smoser> i didnt realize mdev was actually in use anywhere.
[16:49] <smoser> i had seen it in buildroot and the like, but didn't realize it was used for anything larger
[16:49] <minimal> yupe, remember Alpine comes from a minimal (no pun intended) background which is why it also prefers busybox or other stripped down alternatives to standard tools
[16:51] <minimal> I'll add a comment in the PR in reply to igalic but in summary if you are using the Alpine packaged version of cloud-init then udev will be present.
[16:57] <minimal> smoser: I think Archlinux and Voidlinuxmight also have mdev.
[17:13] <meena> minimal, does your package depend on bash?
[17:14] <minimal> nope, Alpine has ash by default. Have I missed some bash script actually used in cloud-init?
[17:15] <minimal> on the link I posted in my MR comments on the top right of the page is a Depends dropdown
[17:24] <meena> minimal, OpenNebula and Illumos need it, everything else used sh
[17:25] <meena> smoser, to summarise: minimal => Alpine, meena => FreeBSD
[17:26] <minimal> Alpine doesn't use typical sysvinit for example with scripts written in either Sh or Bash, it uses OpenRC instead (like Gentoo, indeed for cloud-init we re-use the Gentoo files in the cloud-init repo)
[17:26] <minimal> meena: Alpine is minimal but "minimal" is not Alpine ;-)
[17:27] <smoser> it'd be more helpful if one of you changed your name....
[17:27] <smoser> is that too much to askk ?
[17:27]  * smoser ducks
[17:27] <minimal> smoser: to mo-minimal? ;-)
[17:27] <minimal> or you mean something not beginning with "m"? sure there's 25 options to choose from....
[17:30] <smoser> bummer. it appears you have to use ascii.
[17:30] <smoser> or at least my attempt at changing my nick to ⓜoser failed
[17:32] <meena> IRCv3 surely will fix that
[17:32] <minimal> I could change my name to "niche" (i.e. Alpine) and meena to "almost-niche" (i.e. FreeBSD) ;-)
[17:33] <smoser> ♏ini♏al
[17:34] <minimal> mini-me?
[17:36] <otubo> smoser: should cloudinit/cmd/main.py have python shebang? Fedora build is complaining that I'm not packaging it with an executable flag
[17:37] <otubo> And I'm trying to set 755 on the specfile but it's worthless
[17:37] <smoser> i dont htink it should... i wonder why it would think it should.
[17:38] <otubo> smoser: look https://fedora.softwarefactory-project.io/zuul/build/b799345fa34f48d3a21674d369fc4bc3
[17:38] <otubo> smoser: you don't think it should have a shebang or be executable? :)
[17:38] <smoser> i think the shebang should just be dropped
[17:38] <otubo> oh nice, much easier
[17:39] <smoser> Odd_Bloke or blackboxsw  ? agree/disagree ?
[17:39] <smoser> (and its wrong anyway at this point)
[17:41] <blackboxsw> smoser: otubo I think it can be dropped and perms set to 644 on main.py right?
[17:41] <blackboxsw> running cloud-init CLI with that change (perms and dropped shebang) wfm
[17:41] <otubo> blackboxsw: it's already 644, rpmlint is complaining that it has shebang && is 644
[17:42] <otubo> blackboxsw: nice thanks :)
[17:42] <blackboxsw> oops I misread long listing on my vm
[17:42] <blackboxsw> right 644 already
[17:43] <smoser> yeah. otubo  submit PR ?
[17:44] <otubo> smoser: right away
[17:44] <blackboxsw> looks like the only file with that shebanh
[17:44] <blackboxsw> looks like the only file with that shebang
[17:49] <otubo> smoser: blackboxsw  https://github.com/canonical/cloud-init/pull/722
[17:54] <Odd_Bloke> falcojr: blackboxsw: lucasmoura: First SRU verification PR up: https://github.com/cloud-init/ubuntu-sru/pull/168
[18:01] <blackboxsw> Odd_Bloke: approved
[18:03] <Odd_Bloke> Thanks!
[18:05] <Odd_Bloke> I'm still having issues running xenial LXD VMs on my machine for some reason; could someone who _can_ run `CLOUD_INIT_OS_IMAGE=xenial CLOUD_INIT_PLATFORM=lxd_vm CLOUD_INIT_CLOUD_INIT_SOURCE=PROPOSED pytest --log-cli-level=INFO tests/integration_tests/bugs/test_lp1897099.py` for me and pastebin the output?
=== ijohnson is now known as ijohnson|lunch
[18:56] <powersj> Odd_Bloke, https://pastebin.ubuntu.com/p/MvZSJ6PptB/
[18:57] <powersj> that was against master
[20:06] <Odd_Bloke> powersj: Perfect, thanks!
=== ijohnson|lunch is now known as ijohnson
[20:27] <Odd_Bloke> falcojr: https://github.com/canonical/cloud-init/pull/723 <-- the corresponding cloud-init pycloudlib dependency bump
[20:46] <Odd_Bloke> Next SRU verification PR: https://github.com/cloud-init/ubuntu-sru/pull/169
[20:50] <Odd_Bloke> And another one: https://github.com/cloud-init/ubuntu-sru/pull/170
[21:04] <Odd_Bloke> And: https://github.com/cloud-init/ubuntu-sru/pull/171
[21:16] <Odd_Bloke> Still going: https://github.com/cloud-init/ubuntu-sru/pull/172
[21:17] <chillysurfer> can anybody confirm this: cloud-init dhclient cannot work if /var/tmp is noexec, is that right? https://github.com/canonical/cloud-init/blob/master/cloudinit/net/dhcp.py#L160-L164 seems to validate that
[21:18] <chillysurfer> the "needs exe" dir is /var/tmp: https://github.com/canonical/cloud-init/blob/00dbc1447bbf8ecf611653a1af50af958ac5aeb4/cloudinit/temp_utils.py#L11
[21:25] <rharper> chillysurfer: yes.. that sounds right;  cloud-init copies a dhclient there to run it in a way that won't leave artifacts on the rootfs that we might not be able to easily remove (dhclient script hooks) etc.
[21:29] <chillysurfer> rharper: thanks for the confirmation!
[21:31] <rharper> chillysurfer: you may be interested in this recent (Aug 2020) commit to this region of code; db86753f81af73826158c9522f2521f210300e2b
[21:32] <rharper> which addresses this: https://bugzilla.redhat.com/show_bug.cgi?id=1857309
[21:32] <ubot5> bugzilla.redhat.com bug 1857309 in cloud-init "[Azure][RHEL 8] cloud-init Permission denied with the use of mount option noexec" [High,Verified]
[21:32] <rharper> though, I would say, that does leave the potential for artifacts around on the system since it runs the original dhclient path
[21:34] <chillysurfer> rharper: what is the point of copying dhclient and then running the copied version?
[21:44] <rharper> chillysurfer: as I said, to prevent leaving artifacts on the system due to running dhclient;  it execs scripts in the OS which may do things like write nameservers and *anything* that you want via hooks;
[21:45] <rharper> this dhclient runs very early to bring up networking to query IMDS;  the IMDS result may send a network config which doesn't even specify DHCP etc ...
[21:46] <rharper> ideally cloud-init would use a python-based dhcp client so we don't have to use anything from the OS or leave anything around; but it's not something that's been implemented yet;
[21:48] <chillysurfer> rharper: makes sense thanks!
[22:34] <meena> skipping modules 'ssh-import-id' because they are not verified on distro 'freebsd'
[22:35] <Odd_Bloke> And my last one for the day (and week): https://github.com/cloud-init/ubuntu-sru/pull/173
[22:36] <Odd_Bloke> falcojr: Thanks for all those reviews!
[22:43] <blackboxsw> have a good one Odd_Bloke
[23:16] <falcojr> Happy weekend!