[12:35] <oznt> hi guys, just a quick question: how does cloud init translate "set-passwords" in cloud_config_module to "cc_set_passwords" ? Can't figure this one out
[12:47] <oznt> Well, I found out myself : https://github.com/canonical/cloud-init/blob/7c88f96245535aacfac9b0b04d9c0d82ac2067f4/cloudinit/config/__init__.py
[13:12] <lucasmoura> blackboxsw, thansk for the review :) I will start working on the proposed changes today
[13:36] <Odd_Bloke> oznt: Was that your entire question, or is there anything else we can help you out with?
[13:38] <oznt> Odd_Bloke, that was the question
[14:18] <Odd_Bloke> OK, great. :)
[17:06] <Odd_Bloke> falcojr: I've pushed the requested changes to both https://github.com/canonical/cloud-init/pull/354 and https://github.com/canonical/cloud-init/pull/349 :)
[17:31] <falcojr> cool, I'll re-review now
[17:32] <falcojr> I've technically already approved on the second one, you just need another approval from a committer
[17:33] <usrdev> hello all - hope you are safe and well! just a quick question. when utilizing cloud-init to create templates, i have noticed that the startup script for network configuration is severely delayed. i have cloud-init to pull a DHCP lease, and this works without issue for directly standing up VM from an ISO. i am utilizing proxmox as the HV.
[17:33] <usrdev> is there something i am missing to make this DHCP lease request, quicker...
[17:42] <Odd_Bloke> blackboxsw: Can you add https://github.com/canonical/cloud-init/pull/349 to your list of PRs to double-check as core committer, please?
[17:44] <Odd_Bloke> We also didn't assign reviews today, and I'm first so I've taken #358.
[17:59] <blackboxsw> Odd_Bloke: yes I can/will
[18:40] <AnhVoMSFT> @Odd_Bloke, did you have a chance to take a look into the issue with the test_conftest having pylint error https://pastebin.ubuntu.com/p/QMkhNtShjW/
[19:30] <Odd_Bloke> AnhVoMSFT: I didn't, apologies!
[19:30] <Odd_Bloke> Let me take a quick look now.
[19:36] <Odd_Bloke> AnhVoMSFT: Hmm, could you give me a more recent log?  I'm seeing differences in package versions, and it's hard to tell if that's just because there have been releases in the past ~week.
[19:51] <Odd_Bloke> AnhVoMSFT: Hmm, actually, this is stranger than that.  I can reproduce the error if I give the exact path (i.e. `.tox/pylint/bin/python -m pylint cloudinit/tests/test_conftest.py`), but not if I only specify the directory (i.e. `.tox/pylint/bin/python -m pylint cloudinit/tests/`).  I'm also running Python 3.8 (instead of, I think, 3.5 in these logs).
[19:59] <Odd_Bloke> AnhVoMSFT: And I also can't reproduce on 3.5, using tox. :/
[20:08] <AnhVoMSFT> @Odd_Bloke yeah, I am having a hard time reproducing on my local machine - let me try with the .tox/pylint/bin/python. That should be the same version though
[20:10] <AnhVoMSFT> yes I can repro using that particular command
[20:10] <AnhVoMSFT> and I am on 3.5.2 on my xenial box (python3 --version)
[20:10] <AnhVoMSFT> the build server gets a new container every time it runs the test, so whatever is in .tox isn't cached between runs
[20:46] <Odd_Bloke> AnhVoMSFT: OK, I think we're dealing with some sort of pylint bug here: I see different output for `.tox/pylint/bin/python -m pylint -j1 cloudinit.tests.test_conftest cloudinit.tests.test_util` and `.tox/pylint/bin/python -m pylint -j1 cloudinit.tests.test_util cloudinit.tests.test_conftest`.  Can you confirm you see different behaviour also?
[20:56] <Odd_Bloke> AnhVoMSFT: I'm filing a pylint issue now, will drop the link here once I have done so.
[21:11] <Odd_Bloke> AnhVoMSFT: https://github.com/PyCQA/pylint/issues/3611
[21:20] <AnhVoMSFT> yes @Odd_Bloke I can confirm I am seeing different behaviors between those two commands
[21:21] <AnhVoMSFT> how did the different ordering could come up in one build environment vs the others though?
[21:21] <AnhVoMSFT> Oh, is this because the container we were running the test had only one core ?
[21:24] <AnhVoMSFT> @Odd_Bloke: I guess the question now is: which one of them was the right one? (I know we want a consistent behavior, but which one is the "right" consistent behavior?)
[21:39] <Odd_Bloke> AnhVoMSFT: So I think it's actually more likely that the container had many cores: I think the error is only reported if test_conftest is the _first_ module that a worker process tests (as I've just posted to the issue).
[21:40] <Odd_Bloke> (The number of CPUs in the host is almost certainly what pylint will discover.)
[21:41] <Odd_Bloke> AnhVoMSFT: So in this case, that test is specifically testing for behaviour when the wrong arguments are called (i.e. exactly what this pylint check is warning us about :p).  So it's a valid pylint error, which we should be ignoring in this specific case.
[21:41] <Odd_Bloke> However, I bet we also have a whole load of other instances of this error (or others which are similarly buggy).
[21:52] <blackboxsw> lucasmoura: thanks one minor nit on https://github.com/canonical/cloud-init/pull/359
[21:52] <blackboxsw> then we can land that