=== cpaelzer__ is now known as cpaelzer
[13:52] <otubo> smoser: according to git blame, you were the one who wrote the big part of cloudinit/net/__init__.py, I was reading through and couldn't fully understand the usage of tmp_name. Why do we need to change to a tmp_name?
[13:55] <otubo> [context] I'm working on this bug https://bugzilla.redhat.com/show_bug.cgi?id=1846649, I can observe errors like these: https://pastebin.com/F96hYYhV
[13:55] <ubot5> bugzilla.redhat.com bug 1846649 in cloud-init "Network Interface name suddenly appears as cirename0" [High,New]
[13:55] <meena> la la la la https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#cloudinit-net-cloudinit-distros-networking-hierarchy la la la https://bugs.launchpad.net/cloud-init/+bugs?field.tag=net-refactor la la la la
[13:56] <otubo> smoser: also I believe the error messages on the paste might not be related...
[13:56] <otubo> meena: omg :-o
[13:59] <otubo> meena: do you know about a work in progress for this refactor? Or it's just launchpad bug at the moment?
[13:59] <meena> otubo: i'm currently working on https://github.com/canonical/cloud-init/pull/588
[13:59] <meena> otubo: and Odd_Bloke has done two or three already
[14:01] <meena> oh, wow, i got praised by smoser: https://github.com/canonical/cloud-init/pull/625#pullrequestreview-522690947
[14:01] <meena> anyway, i have to go now; this meeting took a lot longer than 1 h, even tho it was supposed to be a lot shorter than that.
[14:03] <otubo> meena: thanks for the pointers, I'll read it through!
[14:03] <meena> so; i think what i'm suggesting is; rather than trying to fix anything in cloudinit/net, we should move it to coudinit/distro/networking
[14:04] <meena> often times, the act of ripping out, and moving it over, exposes a lot of breaking points that shouldn't be there.
[14:06] <otubo> meena: agreed. But I really need to fix it for 18.5, which is the version the customer is running on their setup :(
[14:06] <otubo> And since I'm gonna fix it for 18.5 will be useless for the refactoring :D
[14:07] <meena> prfffffftttt
[14:07] <meena> but, okay :P
[14:08] <otubo> ¯\_(ツ)_/¯
[15:04] <otubo> Also, quick question for Openstack people out there: How do I change the content of files in config-drive?
[16:57] <meena> who can tell me why we have a dependency on bash?
[17:56] <smoser> meena: it looks to me like it might just be write_boot_content in SmartOS and parse_shell_config in OpenNebula
[17:57] <meena> can we fix that to be posix, smoser?
[18:00] <smoser> well, the "parser" in OpenNebula  definitely wont work with just replacement of /bin/sh
[18:01] <smoser> we need *some* way to read the shell "config" language they have there.
[18:02] <smoser> and on SmartOS i would think that if /bin/bash was not present, then using /bin/sh is reasonable.
[18:02] <meena> ah, aaahhh
[18:03] <smoser> because the alternative there is just failing .
[18:03] <meena> I'm just trying to minimise dependencies on FreeBSD
[18:03] <smoser> you can read the docstrin there... i remember arguing that no-shebang is a broken idea and that we should just try to execute it and be done with that.
[18:03] <smoser> its a weird thing.. "operator-script" and "user-script".
[18:04] <smoser> if i told you "hey, execute this script for me"
[18:04] <smoser> but didn't tell you if it was python or perl or sh or expect, what is the right thing to do ?
[18:04] <smoser> meena: but  yeah... i think we probably dont really have a hard dependency on bash. and that you could fix those two things. with OpenNebula being more difficult.
[18:05] <meena> file *
[18:05] <smoser> what would that tell you on a python program that had no shebang ?
[18:05] <meena> yeah, unfortunately, FreeBSD doesn't have a concept of recommends / suggests
[18:06] <smoser> wow.that is nutx.
[18:06] <smoser> $ file /tmp/doit
[18:06] <smoser> /tmp/doit: Python script, ASCII text executable
[18:06] <smoser> it actually figured it out.
[18:06] <meena> but which version of python?
[18:06] <smoser> https://paste.ubuntu.com/p/3DywCmcNjG/
[18:06] <smoser> yeah.
[18:07] <smoser> so... i think its silly that they provide you with a blob (which might be text or mibht be a binary) and expect you to execute it.
[18:07] <smoser> when it might not have a shebang
[18:07] <smoser> but... that was years ago, perhaps they've fixed.
[18:07] <meena> is this SmartOS or OpenNebula?
[18:08] <meena> https://github.com/canonical/cloud-init/pull/636 ⬅️ this pr was a ride
[18:09] <meena> I'm glad nobody has merged the first iteration
[18:09] <smoser> smartos behavior is to execute a "operator script" with bash if it has no shebang.
[18:09] <smoser> opennebula uses shell as a config language.
[18:10] <meena> https://launchpadlibrarian.net/504093805/freebsd-fs.patch <= first iteration was the first hunk here
[18:10] <meena> smoser, aye
=== MAbeeTT_ is now known as MAbeeTT
[21:44] <meena> very different approach to the UFS (can-skip) resize issue: https://github.com/canonical/cloud-init/pull/655/files positive & negative case validated by tests
[21:48] <meena> let's be honest here, i'm circling these dozens of issues and fixing them, and adding """easy""" tests, so i can get back more confidently to generate_fallback_network tests
[23:30] <ms24> Hello All - Im running Bionic on Vmware and have cloud init scripts that configures my machine - whenever I boot the VM - the Plymouth Spalsh screen appears and then I see the cloud-init running the scripts - Is there a way to hide the cloud-init verose log appearing during boot and run it in the background ? Thanks