[00:34] <minimal> blackboxsw: BTW which bootloader are you using? out of interest I tried forcing metadata_csum_seed when creating a disk image using an older version of mkfs.ext4 and it turns out that Grub doesn't support that
[12:26] <greatgatsby_> Hi.  When I use the jinja template header, my config raises a schema warning.  Here, I just copied the example directly from the cloud-init docs:
[12:27] <greatgatsby_> https://bpa.st/TQFIW
[12:34] <aciba[m]> Hi gratgatsby_, the schema command operates on already rendered cloud-configs https://cloudinit.readthedocs.io/en/latest/reference/cli.html#schema
[12:34] <aciba[m]> to validate the rendered config on the system: sudo cloud-init schema --system
[12:35] <aciba[m]> to manually render a config: cloud-init devel render ...: https://cloudinit.readthedocs.io/en/latest/reference/cli.html#render
[12:35] <greatgatsby_> aciba[m]: thanks for the reply.  I'm pushing something like this out in my openstack vendordata and I get that warning in my cloud-init logs.  I personally don't care too much, but it kind of stands out for our clients.
[12:36] <greatgatsby_> aciba[m]: yes, if I run `cloud-init schema --system` I get the same warning
[12:41] <aciba[m]> I see, if the warning is the logs, I guess cloud-init should at least skip schema validation on ## template: jinja and other valid headers
[12:43] <greatgatsby_> appreciate the help, still testing here, and still quite possibly a pebkac
[12:45] <aciba[m]> greatgatsby_: we added schema validation for vendordata recently: https://github.com/canonical/cloud-init/commit/bb414c7866c4728b2105e84f7b426ab81cc4bf4d
[12:45] -ubottu:#cloud-init- Commit bb414c7 in canonical/cloud-init "disk_setup: use byte string when purging the partition table (#2012)"
[12:46] <aciba[m]> wrong link, this is the correct one: https://github.com/canonical/cloud-init/commit/55686b977570a6de69bef51c1e1a9d452333995d
[12:46] -ubottu:#cloud-init- Commit 55686b9 in canonical/cloud-init "cli: schema also validate vendordata*."
[12:47] <aciba[m]> previously cloud-init didn't validate vendor-data and I guess jinja configs are not a common use-case for user-data
[12:49] <aciba[m]> greatgatsby_: would you mind reporting a bug? https://cloudinit.readthedocs.io/en/latest/howto/bugs.html
[12:51] <greatgatsby_> aciba[m]: will do, I'll keep testing a bit to make sure this isn't a red herring.  Just to be clear, we have a vendordata.json which contains a cloud-init key.  The value for that key is a cloud-config string which starts with the `## template: jinja` header.
[12:51] <cjp256> If I run pytest against one module test_azure.py a bunch of tests fail after the "optimize datasource detection" commit due to subp flagging is_container checks.  but If I instead run tests/unittests/sources it does not fail.  The fixture setup looks the same in both cases, any idea what I'm missing here?
[12:55] <greatgatsby_> aciba[m]: particularly for vendordata, we need jinja since this has to support all the various image distros and versions in our openstack environment
[12:55] <aciba[m]> cjp256: That's sound like there is some leak in the test suite execution / setup, and only works in a particular order.
[12:59] <aciba[m]> greatgatsby_: yes, that is going to work. The only problem is that cloud-init is issuing an invalid cloud-config warning in the logs that it is incorrect, IIUC.
[13:00] <greatgatsby_> correct, just wanted to make sure I was explaining myself correctly.  The cloud-config does execute correctly, it's just the warning.  Once I confirm this isn't something I'm doing wrong on my end, I'll submit a ticket.  Thanks for the help.
[13:05] <greatgatsby_> aciba[m]: appreciate the help, maybe I'm misunderstanding this warning, I had assumed it was my vendordata as that's all I'm providing.  cloud-init schema --system gives `File None needs to begin with "#cloud-config"`.  What is "File None" ?
[13:12] <aciba[m]> greatgatsby_: None sounds like a Python uninitialized variable, it should point to the file in question.
[13:25] <greatgatsby_> ok - so I found in the logs, cloud-init is writing an empty cloud-config.txt file.  In cloud-init schema.py if config_path is None, this is the file it loads and validates.  At least in the master branch, a None config_path doesn't seem supported anymore?
[13:25] <greatgatsby_> https://github.com/canonical/cloud-init/blob/ubuntu/22.4.2-0ubuntu0_22.04.1/cloudinit/config/schema.py#L613
[13:25] <greatgatsby_> anyway, just providing some info, I'm still not convinced this isn't something I'm doing wrong somewhere :-)
[13:34] <greatgatsby_> aciba[m]: sorry if I wasted any of your time, it's possible something changed during an upgrade and now openstack is pushing out an empty cloud-config.txt in the vendordata blob
[13:38] <aciba[m]> greatgatsby_: no worries! if you find anything wrong please report it so that it can get fixed, thanks :)
[21:27] <holmanb> cjp256: I don't see the same thing as you.
[21:28] <holmanb> cjp256: https://dpaste.org/OF6pu
[21:36] <cjp256> holmanb: running same command https://dpaste.org/OFC20
[21:38] <holmanb> heh, it looks like I broke a thing or two 
[21:49] <cjp256> mostly curious why running it as a directory works :D
[21:54] <holmanb> that's very curious
[21:56] <holmanb> I would expect  test_aliyun.py and test_altcloud.py to run before test_azure.py, maybe something in one of them has unclean state that make this pass when running it as a directory?
[21:59] <holmanb> does it do the same with `tox -r -e py3 tests/unittests/sources/test_azure.py`?
[22:09] <cjp256> i forced azure to run first by using `tests/unittests/sources/test_azure.py tests/unittests/sources`... fixture setup looks the same and test sequence is the same so idk :D
[22:48] <cjp256> well that was interesting
[22:49] <cjp256> it's a combination of the lru_cache() on is_container() and test_smartos invoking get_smartos_environment() on module load https://github.com/canonical/cloud-init/blob/main/tests/unittests/sources/test_smartos.py#L1346
[22:50] <cjp256> holmanb: ^
[22:51] <cjp256> holmanb: get_smartos_environment() calls sys.read_dmi_data() which invokes is_container() prior to fixture setup
[22:58] <holmanb> interesting
[23:02] <cjp256> `pip install pytest-antilru` :D
[23:02] <holmanb> hehe
[23:02] <holmanb> caching makes nearly everything more difficult to reason about and test
[23:05] <holmanb> also loading caches at module load time is a recipe for mischief
[23:06] <cjp256> yeah pytest-antilru seems to work fine here, maybe worth adding to the project's test-requirements?
[23:11] <cjp256> looks like it wraps lru_cache before module imports so it can track the list of caches and clear them for every test run
[23:11] <holmanb> that sounds like a decent idea to me
[23:15] <holmanb> pytest-antilru makes a test fail that previously didn't
[23:15] <holmanb> and it looks like that test is incorrect
[23:21] <cjp256> ah, nice. I opened a PR to see how it'd fare, I have had other test problems that may be related too :D
[23:24] <holmanb> nevermind, I don't see the issue anymore