=== hi is now known as Guest3228
[08:39] <faa> TomasD: freebsd default only sample cobfig, cp cloud.cfg.d/05_logging.cfg.sample cloud.cfg.d/05_logging.cfg
[08:40] <faa> NoCloud perfect work with iso, example sysutils/cbsd
[15:23] <gnawa> Hello, I'm trying to load user-data and meta-data expanding dmi variables as seen in the manual --> https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[15:24] <gnawa> the oly useful variables fouynd in /sys/class/dmi/id are product_serial and product_uuid
[15:24] <gnawa> but I can't see any corrispondence with the variables llisted in the table..
[15:25] <gnawa> I tried __dmi.system-uuid__  --> product_uuid
[15:28] <gnawa> and __dmi.system-serial-number__ --> product_serial
[15:28] <gnawa> but it didn't worked..
[15:29] <gnawa> ah I also tried to use __dmi.chassis-serial-number__ --> chassis_serial
[15:31] <gnawa> is there anyone who can help me ? thank you (sorry for the typos I burnt two fingers in a pitfire yesterday..)
[15:45] <gnawa> the cloud-init log shows: 2023-01-01 15:37:26,739 - DataSourceNoCloud.py[DEBUG]: Seed from http://pxe.gnawa.lan/pxelinux.cfg/__dmi.chassis-serial-number__/ not supported by DataSourceNoCloud [seed=None][dsmode=net]
[15:46] <gnawa> and my PXE config stanza is like:
[15:46] <gnawa> append url=http://pxe.gnawa.lan/images/ubuntu-22.04.1-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://pxe.gnawa.lan/pxelinux.cfg/__dmi.chassis-serial-number__/ cloud-config-url=/dev/null ip=dhcp fsck.mode=skip ---
[16:04] <gnawa> mm okay it looks like the corrispondences between cloud-init variables and dmi values present in /sys/class/dmi/id are correct... as shown by the source code of dmi.py
[16:04] <gnawa> https://github.com/canonical/cloud-init/blob/main/cloudinit/dmi.py
[16:05] <gnawa> "system-uuid": KernelNames("product_uuid", "smbios.system.uuid"),
[16:06] <gnawa>     "system-serial-number": KernelNames("product_serial", "smbios.system.serial")
[16:06] <gnawa> "chassis-serial-number": KernelNames( "chassis_serial", "smbios.chassis.serial"
[16:22] <meena> you're looking at very fresh, unreleased code 
[16:22] <meena> gnawa: unless you're actually running git HEAD, please go look at the corresponding tag for the code causing trouble
[16:25] <gnawa> thank you meena , where I can find the tag ? I know only the version ov cloud-init:
[16:25] <gnawa> root@ubuntu-server:/var/log# cloud-init --version
[16:26] <gnawa> usr/bin/cloud-init 22.2-0ubuntu1~22.04.3
[16:27] <gnawa> oh okay the release tag
[16:27] <gnawa> now I see it
[17:00] <minimal> gnawa: what version fo cloud-init are you using?
[17:01] <gnawa> cloud-init 22.2-0ubuntu1~22.04.3
[17:01] <minimal> gnawa: the dmi variable support was only recently added to git main, it is not present in any release yet
[17:03] <minimal> so this functionality will appear in cloud-init 23.1 whenever it is released around February/March time
[17:07] <gnawa> ok got it, thank you!
[17:07] <minimal> gnawa: so the document for the version you are running is~: https://cloudinit.readthedocs.io/en/22.2/topics/datasources/nocloud.html
[17:08] <minimal> the documentation site defaults to "latest" which reflects the git "main~" branch, you need to select the version you are using to see its dos
[17:13] <gnawa> thank you minimal, I understand my mistake ...
[17:31] <minimal> gnawa: you weren't the person trying the same dmi stuff on Alpine Linux a few days ago?
[17:32] <gnawa> minimal no it wasn't  me
[17:33] <minimal> ah ok, they asked the same question but don't seem to have come back to see if anyone answered
[17:46] <minimal> meena: I'm seeing test failures when I enable freebsd for the modified cc_ca_certs.py that I have here - but the failures are unrelated to any certificate stuff, when the test harness "get_cloud" function (in tests/unittests/util.py) is called for "freebsd" it ends up trying to do a "ifconfig -a" for some reason - seems to be related to cloudinit/distros/networking class BSDNetworking being called
[17:57] <meena> aye, i haven't mocked away all of those yet
[17:58] <meena> minimal: my ifconfig parser gets initialised in BSDNetworking, which gets instantiated in FreeBSD distro class. that instantiation calls ifconfig -a
[18:00] <minimal> meena: yes, so for my revised cc_ca_Certs.py its tests are failing due to an unexpected subp for "ifconfig -a"
[18:02] <meena> you can mock it with an empty string, since you don't care about networking paths
[18:03] <meena> https://github.com/canonical/cloud-init/pull/1779
[18:03] -ubottu:#cloud-init- Pull 1779 in canonical/cloud-init "Net: add BSD ifconfig(8) parser and state class" [Merged]
[18:04] <meena> however, i think i have examples there doing only the initialisation with an empty string
[18:04] <minimal> some of those testcases do use/check subp for certs purposes so I'd need to change those to also expects "ifconfig -a" for freebsd
[18:06] <meena> see with mock
[18:06] <minimal> e.g. some testcases when testing freebsd will expect to see a subp for "certctl"
[18:06] <meena> that's usually where the instantiation happens
[18:08] <meena> have not figured out yet, how to do that in python
[18:10] <minimal> so for example the 1st test to fail is TestConfig.test_correct_order_for_remove_then_add in tests/unittests/config/test_cc_ca_certs.py
[18:11] <minimal> tox shows AssertionError: Unexpectedly used subp.subp
[18:11] <minimal> that testcase does nothing with subp at all
[18:22] <meena> that's annoying, let's see how to best fix it
[18:24] <meena> https://github.com/canonical/cloud-init/blob/main/tests/unittests/config/test_cc_ca_certs.py#L169 in here, i'd do:
[18:25] <meena> this: https://github.com/canonical/cloud-init/blob/main/tests/unittests/config/test_cc_power_state_change.py#L89 
[18:26] <meena> minimal: that make sense? 
[18:33] <minimal> ok, let me try that
[18:38] <meena> the basic idea is: if it's network related, load in the appropriate ifconfig asset, if not, load ''
[18:54] <minimal> ok, that seems to have done it, I added this:
[18:54] <minimal> +            if distro_name == 'freebsd':
[18:54] <minimal> +                mock.patch(
[18:54] <minimal> +                    "cloudinit.distros.networking.subp.subp",
[18:54] <minimal> +                    return_value=("", None),
[18:54] <minimal> +                )
[18:56] <meena> no with mock.patch? hmm, yeah, i guess
[18:58] <minimal> that's using mock.patch
[18:59] <meena> I might see if any of the mocks i added need the "with" 
[20:31] <meena> minimal: su what's your patch look like? 
[20:57] <minimal> meena: patch to fix the freebsd issue or the patch in general?
[22:28] <meena> minimal: general
[22:36] <minimal> meena: it's quite a few changes, fixing alpine/debian/ubuntu behaviour as it wasn't correct, likely fixing/changing rhel behaviour and adding freebsd support
[22:37] <minimal> I'm currently testing it locally for alpine, then have to run a fedora VM to verify that