| 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 | 00:34 |
|---|---|---|
| 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:26 |
| greatgatsby_ | https://bpa.st/TQFIW | 12:27 |
| 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:34 |
| 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:35 |
| greatgatsby_ | aciba[m]: yes, if I run `cloud-init schema --system` I get the same warning | 12:36 |
| 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:41 |
| greatgatsby_ | appreciate the help, still testing here, and still quite possibly a pebkac | 12:43 |
| 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:45 | |
| 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:46 | |
| 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:47 |
| aciba[m] | greatgatsby_: would you mind reporting a bug? https://cloudinit.readthedocs.io/en/latest/howto/bugs.html | 12:49 |
| 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:51 |
| 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:55 |
| 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. | 12:59 |
| 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:00 |
| 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:05 |
| aciba[m] | greatgatsby_: None sounds like a Python uninitialized variable, it should point to the file in question. | 13:12 |
| 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:25 |
| 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:34 |
| aciba[m] | greatgatsby_: no worries! if you find anything wrong please report it so that it can get fixed, thanks :) | 13:38 |
| holmanb | cjp256: I don't see the same thing as you. | 21:27 |
| holmanb | cjp256: https://dpaste.org/OF6pu | 21:28 |
| cjp256 | holmanb: running same command https://dpaste.org/OFC20 | 21:36 |
| holmanb | heh, it looks like I broke a thing or two | 21:38 |
| cjp256 | mostly curious why running it as a directory works :D | 21:49 |
| holmanb | that's very curious | 21:54 |
| 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:56 |
| holmanb | does it do the same with `tox -r -e py3 tests/unittests/sources/test_azure.py`? | 21:59 |
| 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:09 |
| cjp256 | well that was interesting | 22:48 |
| 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:49 |
| cjp256 | holmanb: ^ | 22:50 |
| cjp256 | holmanb: get_smartos_environment() calls sys.read_dmi_data() which invokes is_container() prior to fixture setup | 22:51 |
| holmanb | interesting | 22:58 |
| 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:02 |
| holmanb | also loading caches at module load time is a recipe for mischief | 23:05 |
| cjp256 | yeah pytest-antilru seems to work fine here, maybe worth adding to the project's test-requirements? | 23:06 |
| 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:11 |
| holmanb | pytest-antilru makes a test fail that previously didn't | 23:15 |
| holmanb | and it looks like that test is incorrect | 23:15 |
| 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:21 |
| holmanb | nevermind, I don't see the issue anymore | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!