[11:52] <caribou> Hello people, When rebooting an instance with cloud-init, should the netplan configuration be re-generated ? There is LP: #1847583 that reports this bug but nothing has happened about it
[18:16] <falcojr> caribou: by default we don't expect the configuration to be regenerated every boot
[18:16] <falcojr> but using the userdata from this example, you should be able to
[18:16] <falcojr> https://cloudinit.readthedocs.io/en/latest/topics/events.html#examples
[19:24] <ziirish> Hi falcojr, thanks for the hints. I'm working with caribou on this issue and have already tried this piece of configuration but it doesn't seem to be working either
[19:28] <redkrieg> Hi all, I just ran in to an issue where recent versions of cloud-init weren't able to validate users entries with groups defined.  I found that groups in the schema was changed to only accept a string (instead of an array of strings).  Here's the schema entry: https://github.com/canonical/cloud-init/blob/main/cloudinit/config/schemas/schema-cloud-config-v1.json#L36 and here's the docs showing 
[19:28] <redkrieg> multiple examples that are not currently functional: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups
[19:29] <redkrieg> my intuition says that it should be an array type with string items like ssh_authorized_keys, is this a known regression?
[19:44] <redkrieg> just verified the handler for a list of groups instead of a string is still in the codebase.  I'll submit a small PR to update the schema unless this was intended.  https://github.com/canonical/cloud-init/blob/be19a484e1282e2720ddb357cffce7d70f8bbacf/cloudinit/distros/ug_util.py#L27
[19:54] <falcojr> redkrieg: looks like a case we missed. PR would definitely be welcome
[19:57] <falcojr> ziirish: if you want to open a new bug on launchpad (the one referenced refers to switching instances which is a different use case) with some more context, and post the output from "cloud-init collect-logs", we should be able to take a closer look
[20:13] <ziirish> falcojr: I think I just found what's wrong. The datasource NoCloud doesn't seem to be registered to the BOOT event
[20:15] <ziirish> Do you know if there is any reason for that? If not, I can work on a PR
[20:28] <redkrieg> ran in to an issue running tests with Python 3.10, Sequence can no longer be imported directly from collections and must come from collections.abc instead.  min version on the new path is Python 3.3, but I'm having trouble finding anywhere that specifies what versions of Python cloud-init supports.  If it's 3.3+ I think we can safely change the test, no?
[20:40] <redkrieg> the test in question is lowest-supported-dev, I just realized it's in the pytest library.  looks like lowest-supported-deps specifies pytest==3.3.2 which is broken in Python 3.10
[20:53] <ziirish> falcojr: sorry for the noise, the NoCloud Datasource is indeed listening this event but according to the logs: "Allowed events: {<EventScope.NETWORK: 'network'>: {<EventType.BOOT: 'boot'>}}", but it's not the event it receives, instead I see "Event Denied: scopes=['network'] EventType=boot-legacy". I have then added "boot-legacy" in the "when" list but it doesn't show up in the allowed events... I'll 
[20:53] <ziirish> have to dig deeper into that next week
[21:05] <falcojr> ziirish: you shouldn't need to use BOOT_LEGACY for anything. If you can post the cloud-init.log, I might be able to dig in more. There's no message about 'Applying network configuration' on subsequent boots?
[21:06] <falcojr> redkrieg: Python 3.6+, so yes, we should be able to change that test. Though which test? I thought we had already taken care of all of the collections.abc imports
[21:09] <redkrieg> in tox.ini the lowest-supported-deps section includes pytest==3.3.2 which is before they switched to collections.abc
[21:10] <redkrieg> I don't know enough about why that specific version was chosen to say what the new "lowest supported" should be
[21:14] <redkrieg> > To obtain these versions, check the versions of these libraries in the oldest support Ubuntu distro.
[21:20] <redkrieg> I see, bionic shipped 3.3.2 so that makes sense.  I'm not sure what to do about the tests failing on jammy without breaking bionic and I think perhaps focal too
[21:22] <redkrieg> I'm going about this all wrong.  I'll spin up a focal VM for testing my groups schema PR Monday.  the tests failing on jammy aren't really my problem
[21:24] <falcojr> redkrieg: correct, we use 3.3.2 because of Bionic. Which tests though? We run 3.6-3.11 in our CI and haven't seen any issues
[21:27] <redkrieg> falcojr: https://paste.ubuntu.com/p/zyGkP76nrp/
[21:28] <redkrieg> if you need the full output let me know
[21:29] <falcojr> redkrieg: oooh, I'll only run that env from python 3.6.
[21:29] <falcojr> if things pass for you otherwise, feel free to ignore that for now. I can try to make that a little clearer in the docs or in our tox file
[21:31] <redkrieg> rgr that, thanks for the help
[21:40] <redkrieg> falcojr: the "Please add the Canonical Project Manager or contact" on the contributor agreement is required and I don't know what to put there
[21:41] <falcojr> you can put James Falcon
[21:42] <redkrieg> thanks
[21:46] <falcojr> redkrieg: FYI, if you're going to put up a PR soon, do a rebase before. Just merged a fix to an unrelated CI failure
[22:03] <redkrieg> rgr that.  do you think this needs more than one test case?
[22:20] <redkrieg> falcojr: PR submitted, please let me know if there's anything else that should be tested https://github.com/canonical/cloud-init/pull/1545
[22:33] <falcojr> Sounds good thanks!