| rharper | minimal: https://paste.ubuntu.com/p/xszQq4Vc48/ | 00:02 |
|---|---|---|
| minimal | rharper: Thanks. Should the "import mock" be "from unittest import mock" or "from cloudinit.tests.helpers import mock"? | 00:23 |
| 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:27 |
| rharper | https://paste.ubuntu.com/p/tr6SRWKqjR/ | 00:28 |
| rharper | there, tox is happy with that | 00:28 |
| rharper | minimal: either works | 00:29 |
| minimal | yeah, went with cloudinit.tests.helpers | 00:29 |
| minimal | tests pass fine now. Thanks! Don't really follow the changes you provided, need to read up on Python mock some time | 00:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| GI_Jack | hi | 00:40 |
| GI_Jack | what resources exist for writing your own cloud-init modules | 00:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| rharper | bbiab | 00:48 |
| minimal | rharper: over to you for review. Hopefully this can make it into 20.3 tomorrow. | 02:38 |
| otubo | blackboxsw_, thanks a lot :) | 07:56 |
| otubo | blackboxsw_, any chance to also take a look at https://github.com/canonical/cloud-init/pull/521 | 07:57 |
| 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? | 08:31 |
| 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:14 |
| 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:33 |
| otubo | rick_h, Hi! Yeah, doesn't matter actually, I'd be glad is anyone could review it :) thanks! | 13:34 |
| otubo | *if anyone could review it | 13:36 |
| 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:04 |
| rharper | *directly* | 14:05 |
| crandon | rharper: thx, I cam to the same conclusion. | 14:05 |
| rharper | crandon: +1 | 14:06 |
| crandon | rharper: +1 = ? | 14:09 |
| rharper | crandon: sorry just acknowledging your response; +1 is sometimes used in code review to mark agreement | 14:10 |
| 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:21 |
| falcojr | it's not uncommon to mount /var/tmp as noexec, so does it make sense to copy dhclient somewhere else before running it? | 16:22 |
| minimal | rharper: working on your feedback now | 17:22 |
| rharper | minimal: great | 17:32 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:18 |
| 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. | 18:25 |
| minimal | rharper: cc_ntp.cc, the names.append you suggested (line 393) hitting pylint/flake errors. | 19:02 |
| rharper | ok, I;ll try to clean up in a sec | 19:06 |
| rharper | minimal: what you've pushed to tip ? or some additional delta? | 19:19 |
| minimal | rharper: what I pushed 1 hour ago | 19:22 |
| rharper | and a change I suggested | 19:22 |
| rharper | minimal: looks like just formatting; https://paste.ubuntu.com/p/YgqF4RvjJq/ | 19:34 |
| minimal | rharper: I had a missing "]". Tox passing locally, just pushed again so buildjob should pass fully this time | 19:45 |
| rharper | yeah, and your suggestion works with fewer list joins, so +1 | 19:47 |
| 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:49 |
| rharper | yes | 21:55 |
| rharper | minimal: yeah, that looks great | 21:55 |
| minimal | rharper: So what's left to get this merged? | 22:52 |
| 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:57 |
| rharper | minimal: Thank you for the contribution and active refactoring! | 22:58 |
| minimal | rharper: No problem. Now I can prep to update the Alpine package tomorrow or Friday | 22:59 |
| 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:12 |
| minimal | macjunkie: what about /var/lib/cloud/data/status.json? | 23:15 |
| macjunkie | nope no mention of user-data | 23:15 |
| minimal | that'll show if any error occurred during each of the cloud-init stages | 23:16 |
| macjunkie | i don't see any errors listed | 23:17 |
| minimal | Ubuntu's systemd based, anything in the journal? | 23:18 |
| 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:19 |
| macjunkie | now to fix my f'ing yaml | 23:20 |
| macjunkie | thx | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!