=== vrubiolo1 is now known as vrubiolo [13:05] @Odd_Bloke, sorry for the late response, but it is exactly what @falcojr pointed out. We were having problems with the lxd-agent on the vms without that custom config we have on the profile [14:37] lucasmoura: Ack, thanks! [14:40] blackboxsw: AnhVoMSFT: #684 landed. [14:53] thanks @Odd_Bloke [15:36] blackboxsw: falcojr: I won't be able to prep the release today, I have too much other stuff going on; would the two of you be able to put your heads together to drive it? [15:37] (I can take care of the SRU stuff later in my week, I just mean making sure the upstream release gets cut today.) [15:38] sure, works for me [15:39] Thanks! [15:49] if you cut the release, but the SRU validation isn't done until next week, and you find a load of bugs, the fixes only go into the SRU? [15:51] Fixes will generally go through master first; whether we "restart" the SRU with a new base commit or cherry-pick the fixes into the SRU branches depends a little on what else is now in master, but generally we do "just" restart. [15:52] (They might not go through master if the issues we find are introduced by our distro patching, for example.) [15:54] aye [15:55] I've never seen an SRU cut where we would find "a load of bugs" after that ;). There has been a couple where I have seen one or two bugs that justified a retake [16:08] Yeah, it's rarely a bunch of things, it's more normally where one thing is flawed enough that we can't justify releasing it and fixing it up in a follow-up SRU. [17:13] hey, back again with another problem [17:13] https://pastebin.com/DyBdRxYH [17:13] trying to use disk_setup on archlinux openstack image fails [17:14] https://pastebin.com/WePKG78g [17:20] Krikke: Well, that's no good. I believe the issue is that cloud-init assumes sgdisk will be installed, and so effectively does a `which sgdisk` and then uses the returned value as the sgdisk executable (in this case, `None` >.<). [17:20] So a workaround would be to include sgdisk in the images you're using, if that's possible. [17:21] hmm, adding it to packages probably won't do any good? [17:21] since it would have to be in the base image [17:22] That'll depend on the order they execute in (but I assume we expand the disk before attempting to install potentially-large packages into it, so you're likely correct). [17:23] And, yep, it's done way earlier than package installation. [17:23] Sorry, not "expand the disk", really; just general disk-related operations. [17:23] yeah, I'll have to look into building a custom image [17:24] another bug that could have been caught with types [17:24] * meena fixes her rust hat [17:25] Are these generic Arch images? Because you won't be the only person hitting this if so, so they may want to modify their images to have cloud-init work in them; it might be worth a bug report to them? [17:25] could also try refreshing the openstack one, it should be never [17:25] newer* [17:27] I've been keeping a local copy since I do fast iterations with terraform destroy && terraform apply to create a vm and init it with cloud init [17:27] got the debugging a bit easier now when I figured I can have a ssh key for root :D [17:28] for dev [17:29] ah bummer, same error with a fresh image [17:33] is there a fallback if there's no sgdisk? [17:33] or rather, would there be, if the code worked? [17:39] Ok [17:39] release 20.4 is cut and merged thanks falcojr [17:40] so next steps, let's upload to hirsute [17:41] falcojr: can you provide a signed annotated tag for 20.4 on master when you get a chance [17:42] I actually can't tag master without the permissions [17:42] blackboxsw ^ [17:43] ahh roger, and now we now a perm aaahhh right [17:43] commit bit needed :) [17:43] ok will do those parts [17:45] falcojr: done on tag signing for 20.4, pushed to master. do you have access to upload the upstream 20.4 tarfile to launchpad for the project? [17:46] @blackboxsw, yes, I should be able to do the launchpad pieces === blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next Office Hours: Dec 1 17:15 UTC | 20.4 (Nov 24) | https://bugs.launchpad.net/cloud-init/+filebug [17:47] I just changed the topic since WOOT! we are actually getting an upstream release cut today [17:47] * blackboxsw advertized next cloud-init status meeting as Dec 1 too in topic === ijohnson is now known as ijohnson|lunch [17:56] falcojr: when you finish uploading to the launchpad milestone will you also update the release notes/changelog on https://launchpad.net/cloud-init/+milestone/20.4 too? [17:56] I'm closing release related bugs at the moment [17:56] as fix-released [17:57] yep, currently doing the release notes highlights [17:57] blackboxsw: don't we have a script that does the fix-released on bugs automatically? [17:57] falcojr: lp-bugs-released cloud-init 20.4 1776958 1788915 1813396 1826608 1885527 1888858 1895976 1895979 1897099 1897915 1898997 1900837 1901958 1905440 [17:57] yep [17:57] or you can if you wish [17:57] I was just grabbing the next card down [17:57] oh, just thought you were manually doing that...carry on :D [17:58] sorry, just cataloging the card I grabbed :) [18:16] blackboxsw k...script wasn't working for me so can you double check I did everything? [18:16] uploaded tarball, added release notes and changelog [18:17] milestone is set to release [18:17] falcojr: when done w/ milestone upload of the cloud-init-20.4.tar.gz would you please send the 20.4 release email to the cloud-init mailing list mentioning that we plan to SRU this version of cloud-init to Xenial, Bionic, Focal and Groovy. [18:17] will do [18:17] falcojr: ok, checking now the upload script not working [18:17] UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte [18:17] didn't care to debug it atm [18:17] bah, that's a dependency of the upload script. I bet it's busted. [18:18] no need to care at the moment falcojr since we can upload manually. but can you file an issue against uss-tablelfip then? [18:18] yep [18:18] is that where that script lives? oohh lptools [18:19] either way an issues against uss-tableflip and we can sort that shortly [18:20] actually looks like that one comes from lptools? [18:20] oh, you just said that. I can read [18:20] I'm glad others have that problem [18:23] lol, you're literally checking off items as I open the card to check them off [18:24] haha [18:24] I was just validating the milestone and closing as I figured you were "release emailing" [18:25] I'll leave your checks to you? but I ❤ buliding trello karma points [18:28] also falcojr if you perform the initial steps of Publish to ubuntu/devel release. Then I can sponsor that upload to hirsute [18:29] I remember having issues with the publish last time around [18:29] don't think I had all the correct permissions [18:30] right I think you'll be able to put up a PR, but not actually merge it. I *think(* [18:33] falcor I updated the "Publish to ubuntu/devel release" card as I think you can get far enough to propose a PR against ubuntu/devel, but not actually merge it [18:37] blackboxsw: ok, pushed the branch and created PR [18:37] can't tag either [18:38] cool-ish. I'll re-run on my end, check for diffs/pkg build etc and will merge/sponsor your upload [18:40] meena: If we're on a GPT system, I think we need sgdisk as the code is currently written, but I haven't confirmed that. [19:27] now that 20.4 is finally released…WE CAN FINALLY GET WORKING ON 21.1! [19:31] btw, who ever is triaging bugs on launchpad… if you see anything puppet related, you can ping me, just as well as with the FreeBSD issues! [19:49] falcojr: merged your upload branch to ubuntu/devel for 20.4 https://github.com/canonical/cloud-init/pull/686 [19:49] meena: +1 we will make note of that, puppet == spam meena [19:51] I'm uploading 20.4 to Ubuntu hirsute now [19:53] community-notice: 20.4 is uploaded to Ubuntu hirsute (21.04) and will be in most cloud images within a couple days [ubuntu/hirsute-proposed] cloud-init 20.4-0ubuntu1 (Accepted) [19:53] thanks falcojr for the upload request. [19:55] plan is to SRU 20.4 and any additional commits that happen to land shortly into Ubuntu Xenial, Bionic and Focal and Groovy [20:15] seems I managed to add sgdisk onto an custom built image, however now I'm faced with another error https://pastebin.com/MUUiENsJ [20:16] hmm could be something wrong with the image still [20:16] the binary is an empty file [20:30] yeah seems it was an error on the generation part [20:37] ooh, it managed to do it now [20:41] falcojr: minor comments on https://github.com/canonical/cloud-init/pull/675#pullrequestreview-537884563 [20:42] or really just a request for update on squash commit message [20:46] just a note for those following at home. the SRU process when we undertake it for Ubuntu is fairly significant, and we are trying to cut down on that cost with leveraging the new integration test framework under tests/integration_tests. We'll probably be landiing a number of commits as part of this SRU process to reduce the carrying cost of some of our SRU manual testing from here on out. [20:56] I'm ecstatic, blackboxsw. === ijohnson|lunch is now known as ijohnson [20:57] Krikke: good, i only saw the stacktrace, and was gonna ask for a paste of your user-data [21:03] lucasmoura: Odd_Bloke smoser rharper falcojr are we aware of any other branches that we wanted to wait for prior to starting an SRU of 20.4 to xenial, bionic, focal, groovy? [21:04] * blackboxsw is just wondering about timing and whether we wanted to give the upload into hirsute a bit of settle time (and give us a bit of time to generate some more integration tests for cloud-init) [21:06] falcojr: just merged integration_tests harvesting logs on error https://github.com/canonical/cloud-init/pull/675