=== apollo13_ is now known as apollo13
[12:28] <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:31] <otubo> Odd_Bloke, oh I see you specified you want both :-) Nevermind.
[12:35] <Odd_Bloke> :)
[12:40] <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:43] <Odd_Bloke> otubo: I noticed this when reviewing your generator PR: https://github.com/canonical/cloud-init/pull/452
[12:45] <otubo> Odd_Bloke, Oh, didn't see you already had this PR! Apologies :-)
[12:46] <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:47] <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:48] <otubo> Odd_Bloke, oh nice one, indeed.
[12:54] <Odd_Bloke> Thanks for the review!
[12:59] <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?
[13:10] <meena> Odd_Bloke: i could but its not worth much
[13:17] <Odd_Bloke> :)
[13:25] <Odd_Bloke> Similarly, just looking for a committer +1 here: https://github.com/canonical/cloud-init/pull/452
[13:27] <otubo> Odd_Bloke, I don't think I'm a committer, am I?
[13:29] <Odd_Bloke> Nope, that's Chad, Ryan, Scott and myself.
[13:37] <powersj> ahem
[13:37] <powersj> Odd_Bloke, +1 on 452
[13:40] <Odd_Bloke> powersj: Thanks!
[13:43] <powersj> +1 on 391
[13:44] <Odd_Bloke> Thanks!
[14:51] <meena> otubo: Odd_Bloke tried to give me reviewer permissions before, and it didn't pan out
[14:52] <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.
[15:07] <meena> aaaaaaahh
[15:59] <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
[17:12] <falcojr> whats the point of these "ssh "${SSHOPTS[@]}" ubuntu@$VM_IP -- grep Trace /var/log/cloud-init.log" lines in the manual verification?
[17:13] <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:14] <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:15] <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:16] <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:17] <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:19] <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:20] <rharper> I've got the test written; just a matter of running  it on all of the releases
[17:20] <falcojr> kk
[17:25] <blackboxsw> falcojr: pushed the "! grep Trace" commit  into sru/refactor-manual-clouds
[17:31] <blackboxsw> o/  sparkiegeek
[17:31] <sparkiegeek> \o blackboxsw
[17:34] <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:40]  * 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:42] <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:43] <blackboxsw> ahh user-data for maas comes from the maas seed url. to the instance.
[17:47] <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:48] <blackboxsw> sparkiegeek: not sure if that is what you were looking for as far as context
[17:50] <sparkiegeek> blackboxsw: thanks, that's plenty to chew over
[17:58] <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)
[18:06] <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
[19:29] <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:36] <blackboxsw> good pt. rharper yes focal only
[19:37] <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:38] <rharper> hehe
[19:39] <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
[20:18] <rharper> blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/132/files
[20:19] <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:20] <blackboxsw> falcojr: you didn't grab the above commit for verification did you? ^
[20:21] <falcojr> blackboxsw rharper , no I have not grabbed that one
[20:31] <rharper> blackboxsw: falcojr: ok, I'll take that one next
[20:37] <blackboxsw> lucasmoura: a followup change request on https://github.com/cloud-init/ubuntu-sru/pull/122#pullrequestreview-436136291
[20:38] <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:39] <lucasmoura> blackboxsw, ack
[20:39] <falcojr> blackboxsw yes, I'm doing GCE (should have it done soon)...I could jump or Oracle too
[20:40] <blackboxsw> falcojr: I'll wrap up SRU reviews and ping you to when I'm done to see where we are both at.
[20:41] <falcojr> sounds good
[20:52] <meena> Odd_Bloke: how do i take on one of those cloudinit/net refactor bugs?
[21:04] <meena> never mind, i'm too tired. lol
[21:35] <blackboxsw> heh meena, just assign yourself when intererested
[21:38] <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
[22:26] <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:34] <falcojr> Sounds good
[22:40] <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:44] <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:45] <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