[00:02] <rharper> minimal: https://paste.ubuntu.com/p/xszQq4Vc48/
[00:23] <minimal> rharper: Thanks. Should the "import mock" be "from unittest import mock" or "from cloudinit.tests.helpers import mock"?
[00:27] <rharper> yes
[00:27] <rharper> I'm still working on getting tox to be happy
[00:27] <rharper> I've a few more fixes since that post
[00:28] <rharper> https://paste.ubuntu.com/p/tr6SRWKqjR/
[00:28] <rharper> there, tox is happy with that
[00:29] <rharper> minimal: either works
[00:29] <minimal> yeah, went with  cloudinit.tests.helpers
[00:30] <minimal> tests pass fine now. Thanks! Don't really follow the changes you provided, need to read up on Python mock some time
[00:31] <minimal> Getting 2 flake2 errors about line > 79 which is 2 of the text.dedent lines for the expected content. Is there any way I can split/wrap those lines without it breaking the assert comparison?
[00:33] <rharper> minimal: so, I changed to mocking out your _write_repo_contents method (which called util.write_files)  for the no-write case, it was easier to check the call count on that
[00:34] <rharper> minimal: the second issue was the path to the template files, so I looked at test_handler_cc_ntp.py  and it sets up the helpers.Path object to the same reRooted path (self.new_root) this allowed the module to find the temporary template files it writes
[00:34] <rharper> and the final bit was just extra new line on the dedents
[00:35] <rharper> minimal: see my latest paste, I just left shifted the few tests that were too long
[00:35] <minimal> I should have spotted the missing "\"s on the dedents myself.....
[00:35] <rharper> it's not easy (IMO) to read the assertEqual output expectially for multi-line output
[00:35] <rharper> so I basically do a print(expected); print(); print(actual)
[00:35] <rharper> so I can see what the two things look like
[00:36] <rharper> then it was obvious
[00:36] <minimal> wasn't sure if left-shift the extra long sections would cause flake8 to complain about lack of indent. I'll do that now.
[00:37] <rharper> I think since it's wrapped in a function call it's happy; plain tox came out clean after I did the left shift
[00:40] <GI_Jack> hi
[00:40] <GI_Jack> what resources exist for writing your own cloud-init modules
[00:42] <minimal> Decided to shorten that repositories comment line in both cc module and test_handler to solve to line length problem
[00:42] <rharper> GI_Jack: https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_foo.py   is an example module;
[00:42] <rharper> minimal: =)
[00:42] <GI_Jack> most excellent, thank you kindly
[00:43] <GI_Jack> new interest is writing custom cloud images... :)
[00:43] <minimal> rharper: So just have to look at your ntp test_handler comments now.
[00:44] <minimal> thanks for all your helper. Not sure what timezone you're in but I'm sure its late there
[00:44] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
[00:44] <rharper> minimal: US Central;    np;
[00:45] <rharper> for the ntp one;  that'll take more work;  it really should be a pytest.mark.parametrized ... but that may be a bit steep refactor;
[00:46] <rharper> so I'd be happy with changes to not duplicate code paths with large bodies of if alpine else default ... and try to make the if else as *small* as possible, or use distro_name and/or client lookups into a mapping to adjust the separate results;
[00:48] <rharper> bbiab
[02:38] <minimal> rharper: over to you for review. Hopefully this can make it into 20.3 tomorrow.
[07:56] <otubo> blackboxsw_, thanks a lot :)
[07:57] <otubo> blackboxsw_, any chance to also take a look at https://github.com/canonical/cloud-init/pull/521
[08:31] <b0urne> I launched an windows-server-2016 instance in my cloud environment, When I tried to log on via vnc, the server rebooted. After checked the system log, the server was rebooted by cloud-init. Is this a normal behavior of cloud-init?
[13:14] <crandon> Hi! Is there a way to completely disable IPv6 via cloud-init? While I found the question on some forum I haven't seen any replies nor such option in the official docs
[13:33] <rick_h> otubo:  he's out today. Did you want him to look at it when he gets back or I can ask someone else to peek at it later today
[13:34] <otubo> rick_h, Hi! Yeah, doesn't matter actually, I'd be glad is anyone could review it :) thanks!
[13:36] <otubo> *if anyone could review it
[14:04] <rharper> crandon: it's not a directy cloud-init option, but you could use a bootscript to  run a script which uses sysctl to disable ipv6
[14:05] <rharper> *directly*
[14:05] <crandon> rharper: thx, I cam to the same conclusion.
[14:06] <rharper> crandon: +1
[14:09] <crandon> rharper: +1 = ?
[14:10] <rharper> crandon: sorry just acknowledging your response;  +1 is sometimes used in code review to mark agreement
[16:21] <falcojr> I'm looking at https://github.com/canonical/cloud-init/pull/521 (thanks otubo) and it's working around our DHCP sandboxing, but I'm wondering if we could find a better directory to run dhclient from
[16:22] <falcojr> it's not uncommon to mount /var/tmp as noexec, so does it make sense to copy dhclient somewhere else before running it?
[17:22] <minimal> rharper: working on your feedback now
[17:32] <rharper> minimal: great
[18:05] <AnhVoMSFT> @rharper @blackboxsw_ we have seen a few deployments that failed with these kind of messages "UnicodeEncodeError: 'latin-1' codec can't encode character '\u1ecb' in position 373: Body ('ị') is not valid Latin-1. Use body.encode('utf-8') if you want to send it encoded in UTF-8."
[18:05] <AnhVoMSFT> https://paste.ubuntu.com/p/fqjmzZ38fJ/
[18:06] <AnhVoMSFT> I tracked that down to basically the hostname that the customer specified had some unicode character in it, which results in the instance_id returned from wireserver having the unicode character
[18:07] <AnhVoMSFT> is latin-1 the default encoding that python will use, if I were to encode the body of the report ready request to utf-8 would that help?
[18:18] <rick_h> AnhVoMSFT:  looking at the python code there a comment states it has to be laten-1 per RFC :/ so yea have to encode it first though then the question is what is going to read/decode it after the fact. What is it POST'ing to?
[18:18] <rick_h> AnhVoMSFT:  https://paste.ubuntu.com/p/Pqf5QxvvCp/
[18:25] <AnhVoMSFT> it's posting to the wireserver, a component in the Azure platform. I'm verifying whether it can handle UTF-8. It probably should, since it has been supporting unicode hostname on the Windows side
[18:25] <rick_h> looks like the code around there has changed a bit. send_ready_signal() vs _report_ready() but yea I would expect just needing to encode the data in there somewhere to be wire-safe would be on par
[18:25] <rick_h> interesting on the latin-1 requirement for the RFC in the http library.
[19:02] <minimal> rharper: cc_ntp.cc, the names.append you suggested (line 393) hitting pylint/flake errors.
[19:06] <rharper> ok, I;ll try to clean up in a sec
[19:19] <rharper> minimal: what you've pushed to tip ?  or some additional delta?
[19:22] <minimal> rharper: what I pushed 1 hour ago
[19:22] <rharper> and a change I suggested
[19:34] <rharper> minimal: looks like just formatting; https://paste.ubuntu.com/p/YgqF4RvjJq/
[19:45] <minimal> rharper: I had a missing "]". Tox passing locally, just pushed again so buildjob should pass fully this time
[19:47] <rharper> yeah, and your suggestion works with fewer list joins, so +1
[21:49] <minimal> rharper: Saw you re-wording comment. Happy with this: "By default, cloud-init will generate a new repositories file ``/etc/apk/repositories`` based on any valid configuration settings specified within a apk_repos section of cloud config."?
[21:55] <rharper> yes
[21:55] <rharper> minimal: yeah, that looks great
[22:52] <minimal> rharper: So what's left to get this merged?
[22:57] <rharper> minimal: nothing, I've approved;
[22:57] <rharper> I was waiting for CI to check out as well
[22:57] <rharper> I'll merge
[22:57] <minimal> rharper: Great stuff. Thanks for all your help
[22:58] <rharper> minimal: Thank you for the contribution and active refactoring!
[22:59] <minimal> rharper: No problem. Now I can prep to update the Alpine package tomorrow or Friday
[23:12] <macjunkie> provisioning some AWS instances and referencing a cloud-init template in terraform the template (appears to get end up on the instance) but nothing ever gets executed. I found user-data.txt in /var/lib/cloud/instance on the instance (ubuntu 16) but no activity in /var/log/cloud-init.log etc..
[23:12] <macjunkie> anyone have any ideas?
[23:15] <minimal> macjunkie: what about /var/lib/cloud/data/status.json?
[23:15] <macjunkie> nope no mention of user-data
[23:16] <minimal> that'll show if any error occurred during each of the cloud-init stages
[23:17] <macjunkie> i don't see any errors listed
[23:18] <minimal> Ubuntu's systemd based, anything in the journal?
[23:19] <macjunkie> woohoo found it
[23:19] <macjunkie> "util.py[WARNING]: Failed loading yaml blob. Invalid format at line 24 column 6: "while scanning a plain scalar"
[23:19] <macjunkie> it is processing it
[23:20] <macjunkie> now to fix my f'ing yaml
[23:20] <macjunkie> thx