[00:08] Sounds good. I'll take a look first thing in the morning [10:16] smoser: Thanks! I'll probably go with your approach of removing the lvextend part. I'll send a PR soon. :) [10:30] Hi [10:30] is late_command a key added by ubuntu autoinstall and not cloud-init dependant ? [10:30] how cloud-config differs from cloud-init ? [10:40] https://bugs.launchpad.net/subiquity/+bug/1905731 [10:40] Ubuntu bug 1905731 in subiquity "feature request autoinstall: late_command scripts and chroot key" [Undecided,New] [10:40] is subiquity only manage by mwhudson ? [10:40] oups [10:40] wrong chan [12:46] hey guys, I'm working on the Fedora rebase (20.4) and I'm seeing some weird stuff on the tests, there's 24 of them failing: https://kojipkgs.fedoraproject.org//work/tasks/5682/56695682/build.log [12:46] This is the result of a vanilla 20.4 + 3 irrelevant patches: https://src.fedoraproject.org/fork/otubo/rpms/cloud-init/tree/1902250 [12:48] The tests are being called by the spec file as "nosetests-3.9 tests/unittests/". I don't believe the tests are bogus, but probably some misconfiguration on the spec file, some package version, I don't know and I would love another pair of eyes on this matter :-D [12:48] Don't know who to ping for this, but I'm gonna give it a try with Odd_Bloke who is always ready to help :) [13:57] eoli3n: late_command is not part of cloud-init, it is curtin. [13:58] https://ubuntu.com/server/docs/install/autoinstall-reference [13:58] so, it runs in the installer environment. [14:14] smoser thanks [14:14] does debian supports cloud-config ? [14:16] cloud-init is available on debian, cloud-init supports cloud-config. [14:16] so... dependent upon whether or not cloud-init is installed. [14:17] thanks [14:36] otubo: Those are parameterised pytest tests (e.g. https://github.com/canonical/cloud-init/blob/master/tests/unittests/test_util.py#L954). (As nose doesn't know how to parameterise these tests, the function parameters which would be filled by that parameterisation are instead left unpassed, hence "missing 2 required positional arguments: 'criteria' and 'expected_devlist'".) I think moving to use pytest [14:36] to run these tests will address it. [14:52] Odd_Bloke: Ok it partially fixed it :) Now I got the same issues whenever I run "tox" on my laptop. I wanted to ask this a while ago, this error is being present for a long time, but I always forget. [14:52] Odd_Bloke: https://kojipkgs.fedoraproject.org//work/tasks/5322/56705322/build.log [14:54] I don't see that on travis-ci, but I always see that on my laptop even with an untouched checkout. [14:54] otubo: That looks like insufficient sandboxing to me; we wouldn't have noticed it because every Ubuntu system has /etc/ca-certificates.conf. [14:56] Odd_Bloke: ok, so it's not an obvious misconfiguration on my side. Good to know :D I'll skip those, in the meantime I'll try to fix and send a PR [14:56] Odd_Bloke: Thanks for the help :) [15:01] otubo: Does https://paste.ubuntu.com/p/9PCN3KKfdg/ fix it? [16:50] Odd_Bloke: I'm going through https://github.com/canonical/cloud-init/pull/702 now. thanks! [17:31] falcojr: blackboxsw: Fairly small integration testing PR: https://github.com/canonical/cloud-init/pull/708 [17:32] blackboxsw: Looking at your comment on #702 now. :) [17:34] Odd_Bloke: falcojr, do we expect failures locally from integration_tests tests/integration_tests/modules/test_ssh_keys_provided.py? I've got something amuck on my groovy and focal dev systems causing integration_test failures on master and Dan's PR 702. `tox -e integration-tests-ci tests/integration_tests/modules/test_ssh_keys_provided.py` [17:35] https://paste.ubuntu.com/p/p9czhf7pxD/ [17:36] seems to fail finding /etc/ssh/ssh_host_rsa_key-cert.pub [17:37] We're not expecting failures anywhere, but that doesn't mean we got everything perfect 😉 [17:38] Currently lunching but I'll take a look when I'm back at my desk [17:42] We would expect failures if you aren't specifying a CLOUD_INIT_SOURCE pointing at either master (IN_PLACE, daily PPA) or at proposed (PROPOSED). [17:42] (I wonder if we should change that default behaviour?) [17:45] falcojr: https://github.com/canonical/cloud-init/pull/706/files#r535448031 <-- a nit, which I can fix-and-land if you'd like [17:45] approved https://github.com/canonical/cloud-init/pull/708 and might switch UA client [17:45] approved https://github.com/canonical/cloud-init/pull/708 and might switch UA client integration tests to do the same [17:45] falcojr: (Or, rather, tell me if you _don't_ want me to do that. :) [17:47] approved https://github.com/canonical/cloud-init/pull/702 waiting on CI, will let you merge Odd_Bloke [17:47] and needs a rebase now [17:50] blackboxsw: FWIW, as we squash-merge, there's no reason to rebase instead of hitting "Update branch": the merge commit will be squashed away. [17:51] right right good pt === ijohnson is now known as ijohnson|lunch [18:20] Odd_Bloke: sorry, what are you wanting me to capitalize? [18:22] capitalize RSA or treat the variables as constants? [18:24] also, that merge point is relevant for me too. I have a branch with a conflict and multiple commits, and I was waiting for approval to squash then rebase to avoid the merge commit [18:24] but that won't matter === ijohnson|lunch is now known as ijohnson [20:14] falcojr: Ah yeah, apologies: I meant treat them as constants. [20:14] gotcha, I also commented on the PR (which I should have done in the first place) [20:59] falcojr: Is there any way for me to disable the image cleanup via configuration? I'd like to run with CLOUD_INIT_SOURCE=PROPOSED once, and then just feed the image built by that in as my OS_IMAGE to save myself ~45s per test run. [21:06] hmmm, no, I hadn't considered that use case [21:07] for now you can comment this line, but that's obviously not a long term solution [21:07] https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py#L130 [21:10] Hi folks I have a draft up here: https://github.com/canonical/cloud-init/pull/710 ... I need to write tests and docs and so on still but is that looking about right? [22:46] otubo: I'm out tomorrow, but if that test patch does fix the issue, feel free to put up a PR with it so we don't lose it. :)