=== apollo13_ is now known as apollo13 | ||
otubo | Odd_Bloke, quick question on PR 428: Would you like a unittest for kernel_version() function? We already have tests for swap file. | 12:28 |
---|---|---|
otubo | Odd_Bloke, oh I see you specified you want both :-) Nevermind. | 12:31 |
Odd_Bloke | :) | 12:35 |
otubo | Odd_Bloke, but I'm not sure I can test the kernel_version function without issuing os.uname() again. I would have to hard-code a kernel version assuming I know the actual kernel version in where the test will run. | 12:40 |
Odd_Bloke | otubo: I noticed this when reviewing your generator PR: https://github.com/canonical/cloud-init/pull/452 | 12:43 |
otubo | Odd_Bloke, Oh, didn't see you already had this PR! Apologies :-) | 12:45 |
Odd_Bloke | otubo: Oh, no, I noticed that one of the other systemd files was incorrect when I was grepping around to confirm that your change matched the rest of the templates. Your fix already landed, this is a different file. :) | 12:46 |
Odd_Bloke | otubo: Regarding testing kernel_version(), I was thinking that you'd mock out os.uname() and test that if you return a few different valid kernel versions (ideally formatted how we would find across a few different distros) it produces the expected tuple. | 12:47 |
otubo | Odd_Bloke, oh nice one, indeed. | 12:48 |
Odd_Bloke | Thanks for the review! | 12:54 |
Odd_Bloke | Oh, huh, I thought I had a committer +1 on https://github.com/canonical/cloud-init/pull/391 but I don't; could someone give me a +1 so I can hit the green button? | 12:59 |
meena | Odd_Bloke: i could but its not worth much | 13:10 |
Odd_Bloke | :) | 13:17 |
Odd_Bloke | Similarly, just looking for a committer +1 here: https://github.com/canonical/cloud-init/pull/452 | 13:25 |
otubo | Odd_Bloke, I don't think I'm a committer, am I? | 13:27 |
Odd_Bloke | Nope, that's Chad, Ryan, Scott and myself. | 13:29 |
powersj | ahem | 13:37 |
powersj | Odd_Bloke, +1 on 452 | 13:37 |
Odd_Bloke | powersj: Thanks! | 13:40 |
powersj | +1 on 391 | 13:43 |
Odd_Bloke | Thanks! | 13:44 |
meena | otubo: Odd_Bloke tried to give me reviewer permissions before, and it didn't pan out | 14:51 |
meena | my ✅ is still grey | 14:52 |
Odd_Bloke | meena: I gave you enough permissions that we can _request_ reviews from you, we still want to have a committer's +1 even on BSD-specific changes. | 14:52 |
meena | aaaaaaahh | 15:07 |
blackboxsw | sorry lucasmoura just pushed that missing release -> UBUNTU_RELEASE commit to the sru test refactor https://github.com/cloud-init/ubuntu-sru/pull/128 and merged your RandomPassword validatrion | 15:59 |
blackboxsw | validation rather | 15:59 |
falcojr | whats the point of these "ssh "${SSHOPTS[@]}" ubuntu@$VM_IP -- grep Trace /var/log/cloud-init.log" lines in the manual verification? | 17:12 |
falcojr | there's no trace in the logs so the script is failing | 17:13 |
blackboxsw | falcojr: generally with set -ex in the script we should have made that line whats the point of these "ssh "${SSHOPTS[@]}" ubuntu@$VM_IP -- ! grep Trace /var/log/cloud-init.log" | 17:13 |
blackboxsw | sorry if I switched the script to set -ex, I should have adapted those lines to expect no matches | 17:13 |
blackboxsw | or fail quickly if they hit it | 17:13 |
blackboxsw | note the bang "!" above | 17:14 |
falcojr | gotcha. I saw some with a bang and some without, so was wondering | 17:14 |
* blackboxsw looks over the refactor cloud tests and fixes that throughout | 17:14 | |
blackboxsw | gce and azure scripts it seems | 17:15 |
rharper | blackboxsw: btw, this swap: auto for swapfile is a PITA, all of my lxd deployments use ZFS and ZFS does not support swapfiles ... so having to go VM route; lxd vms IIRC don't have cloud-images for Xenial (right? ) so that'll have to be a one-off to get a xenial cloud-image up; should ahve a PR up for that today | 17:15 |
blackboxsw | gce/softlayer I mean , though I ffixed softlayer in the PR https://github.com/cloud-init/ubuntu-sru/pull/130 | 17:16 |
Odd_Bloke | I think we've figured out that you can launch xenial VMs but the lxd agent won't work without the HWE kernel so you can't use any of the `lxc` commands to interact with it. | 17:16 |
Odd_Bloke | Someone else please confirm though, we've been learning a lot over the past couple of days so I might have got mixed up. :p | 17:17 |
blackboxsw | rharper: sorry, right so falcojr was using ssh into the xenial lxc container instead of lxc exec specifically for xenial https://github.com/cloud-init/ubuntu-sru/pull/129 | 17:17 |
blackboxsw | strange thing rharper is that paride was still able to lxc launch ubuntu-daily:xenial --vm --profile <vm_profile> yesterday I thought (and I know I was able to do the same last week, but can no longer do that today) | 17:19 |
rharper | well, I think I'm going to add an ext4 loop device as a storage pool to lxd | 17:19 |
blackboxsw | rharper: trusty via lxc launch --vm is an official "not gonna do it" as far as images. Xenial has some support, and bionic+ is good to go | 17:19 |
rharper | then file-based swaps will work and I can just use the normal lxc path | 17:19 |
falcojr | @rharper I tested some other swap srus | 17:19 |
falcojr | I can take this one too if that's easier | 17:19 |
rharper | I've got the test written; just a matter of running it on all of the releases | 17:20 |
falcojr | kk | 17:20 |
blackboxsw | falcojr: pushed the "! grep Trace" commit into sru/refactor-manual-clouds | 17:25 |
blackboxsw | o/ sparkiegeek | 17:31 |
sparkiegeek | \o blackboxsw | 17:31 |
sparkiegeek | I'm trying to understand how MAAS needs to send user-data to cloud-init for the machines it boots. AFAICT MAAS is currently base64 encoding a script, and sending it as application/octet-stream but I might be misunderstanding | 17:34 |
* blackboxsw is peeking through maas code again to see how cloud-config userdata is specified directly to cloud-init. Generally I believe providing any cloud-init userdata types should be acceptable and interpreted correctly by cloud-init https://cloudinit.readthedocs.io/en/latest/topics/format.html | 17:40 | |
blackboxsw | In maas case, I know that cloud-init gets some user-data/ or at least vendors data through a curtin config passthrough that maas provides (in order to make sure curtin and cloud-init knows how to talk back to the maas proper log/event endpoints). But I don't recall exactly how maas passes cloud-init user-data specifically (whether through curtin config or the maas datasource). | 17:42 |
blackboxsw | ahh user-data for maas comes from the maas seed url. to the instance. | 17:43 |
blackboxsw | so generally, if that user-data exposed to the instance is a supported cloud-init user-data format (link above). Cloud-init should be able to properly interpret it. I see in the MAAS datasource, that cloud-init will attempt to decode the content of user-data url if present. It does expect user-data to be binary encoded content. | 17:47 |
blackboxsw | https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceMAAS.py#L22-L27 | 17:47 |
blackboxsw | sparkiegeek: not sure if that is what you were looking for as far as context | 17:48 |
sparkiegeek | blackboxsw: thanks, that's plenty to chew over | 17:50 |
blackboxsw | -/me merged ubuntSRU verification branch https://github.com/cloud-init/ubuntu-sru/pull/128 will adapt/iterate on the softlayer results. | 17:58 |
blackboxsw | falcojr: I think I handled your initial review comments (and probably expect there may be a couple of extra things you run across in your GCE test run) | 17:58 |
rharper | sparkiegeek: you may also be interested in the curtin handling of maas provided cloud-config, https://git.launchpad.net/curtin/tree/curtin/commands/curthooks.py#n1344 | 18:06 |
rharper | fun fact: eoan, bionic, and xenial never had the bug around swap: {size: auto}; as it was an regression introduced with the fix for fallocate, on Jan 23; 6603706eec1c39d9d591c8ffa0ef7171b74d84d6 ; it only regress focal; blackboxsw so, for SRU verification is it OK to only verify focal ? | 19:29 |
blackboxsw | good pt. rharper yes focal only | 19:36 |
blackboxsw | given we never introduced the bug in the first place.... thank goooodness for not SRUing for 6 months ;) | 19:37 |
blackboxsw | ohh wait carry that cost forward :/ | 19:37 |
rharper | hehe | 19:38 |
rharper | I spent too long trying to figure out why I couldn't recreate on eoan, thinking it was lxd vm related; turns out not a bug in 19.4-33 | 19:39 |
rharper | blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/132/files | 20:18 |
blackboxsw | on it rharper | 20:19 |
rharper | you also mentioned, https://git.launchpad.net/cloud-init/commit/?id=723e2bc1 (nfs style paths) ; is that still open/needed ? | 20:19 |
blackboxsw | rharper: yep in the hidden trello board, still has your gravatar on it :) | 20:19 |
blackboxsw | falcojr: you didn't grab the above commit for verification did you? ^ | 20:20 |
falcojr | blackboxsw rharper , no I have not grabbed that one | 20:21 |
rharper | blackboxsw: falcojr: ok, I'll take that one next | 20:31 |
blackboxsw | lucasmoura: a followup change request on https://github.com/cloud-init/ubuntu-sru/pull/122#pullrequestreview-436136291 | 20:37 |
blackboxsw | falcojr: you are on gce next for SRU verification right? and you don't plan on oracle? | 20:38 |
blackboxsw | if not oracle , then I'll grab it (and re-find my credentials) | 20:38 |
lucasmoura | blackboxsw, ack | 20:39 |
falcojr | blackboxsw yes, I'm doing GCE (should have it done soon)...I could jump or Oracle too | 20:39 |
blackboxsw | falcojr: I'll wrap up SRU reviews and ping you to when I'm done to see where we are both at. | 20:40 |
falcojr | sounds good | 20:41 |
meena | Odd_Bloke: how do i take on one of those cloudinit/net refactor bugs? | 20:52 |
meena | never mind, i'm too tired. lol | 21:04 |
blackboxsw | heh meena, just assign yourself when intererested | 21:35 |
blackboxsw | meena: Odd_Bloke was planning on filing bugs for each aspect of the net refactor and we can have devs assign themselves to each bug and mark it in progress | 21:38 |
blackboxsw | as they carve out the items | 21:38 |
blackboxsw | I'm on https://github.com/cloud-init/ubuntu-sru/pull/133 falcojr for gce verification. minor request for comment on https://github.com/cloud-init/ubuntu-sru/pull/129 to resolve and we can land that | 22:26 |
falcojr | Sounds good | 22:34 |
blackboxsw | lucasmoura: https://github.com/cloud-init/ubuntu-sru/pull/131#discussion_r444497107 I'm not sure what you are asking. should I add the content of sru-vars.template to the verification output for softlayer ? | 22:40 |
blackboxsw | or something else | 22:40 |
lucasmoura | blackboxsw, no no. It is just that in the other cloud providers tests we have the shellscript that generated the output on the report as well, like this for example https://github.com/cloud-init/ubuntu-sru/blob/master/manual/ec2-sru-20.2.45.txt#L1 | 22:44 |
blackboxsw | ahh ahh, I see. yes I will put that in there. an oversight thanks | 22:45 |
blackboxsw | I thought you were specifically asking about including sru-vars.template content alone | 22:45 |
blackboxsw | didn't realize I left it out | 22:45 |
blackboxsw | all of it | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!