=== hjensas is now known as hjensas|afk === MAbeeTT3 is now known as MAbeeTT [14:45] blackboxsw: FYI, I've updated the SRU template in https://bugs.launchpad.net/cloud-init/+bug/1910835 to use the regular SRU process rather than cloud-init's exception: examination of the patch clearly indicates this only modifies Azure code paths, so I don't think we need a full regression test across all clouds. [14:45] Ubuntu bug 1910835 in cloud-init "Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys." [Critical,Confirmed] [14:45] (And I'm running the integration tests in Azure against proposed now.) [15:15] falcojr: I'm seeing https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/bugs/test_gh632.py fail on Azure; I think it's missing a mark to only run on particular clouds, but it's not immediately clear to me which ones it should run on. Could you take a look? === vrubiolo1 is now known as vrubiolo [15:29] blackboxsw: falcojr: Any objection to me fixing the daily builds by merging ubuntu/$series into ubuntu/daily/$series (and fixing conflicts as I do so)? [15:39] I'll take a look at the test [15:39] More specifically: I'll need to merge the packaging branch into the daily branch, and then revert the cherry-pick commit (otherwise we try to apply the cherry-picked quilt patch to master's tree, which already includes that content; unsuccessfully, of course). [15:39] no objection from me, but I'm probably not the one to ask [16:00] Odd_Bloke: falcojr checking. I *thought* we had a tool to do this :) :( [16:04] I think we want to run https://github.com/canonical/uss-tableflip/blob/master/doc/ubuntu_release_process.md [16:04] uss-tableflip/fix-daily-branch [16:05] looks like I need to update docs there. [16:05] something like fix-daily-branch xenial upstream [16:09] blackboxsw: That tool doesn't perform a merge, so it's not clear to me that it does what we need. [16:10] I guess I could run it after the merge, and it would do the revert for me automatically. [16:10] (I did look at it. :) [17:18] +1 Odd_Bloke as you mentioned in standup we can circle back on the tool to make sure it does what it's supposed to (or avoid using it since the manual steps are not too many) === blackboxsw changed the topic of #cloud-init to: 20.4 (Nov 24) | file a bug: https://bugs.launchpad.net/cloud-init/+filebug | pull-requests: https://git.io/JeVed | meeting minutes: https://goo.gl/mrHdaj | next office hours: Jan 12 17:15 UTC [17:20] looks like we missed office hours last week. I'm bumping it to next week unless there are any objections. [17:21] TLDR Odd_Bloke, falcojr working on SRU verification for a cherry-pick fix for Azure for 20.4 expectation is that we'll roll out this images very soon this week. I see verification logs are already attached [17:24] falcojr: I wanted a bug to reference in my SRU comment, so I've opened https://bugs.launchpad.net/cloud-init/+bug/1911230 for the issue we talked about earlier. [17:24] Ubuntu bug 1911230 in cloud-init "`test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds" [Medium,In progress] [17:47] SRU verification is complete, and marked as such in the bug; we're now waiting for review from the SRU team to release it into the archive. [17:56] BOOM! Thanks Odd_Bloke for the heavy lifts there === ijohnson is now known as ijohnson|lunch [18:18] man 315 line DataSourceOVF.py:get_data painful.... [18:18] sooo much nested logic [19:20] Odd_Bloke: how does having a bug to reference help us? [19:35] falcojr: Given the tight turnaround we're asking for, I wanted to be very explicit in our SRU bug about why we were seeing failures in the test results that I posted and that we were in the process of addressing them; if I'd seen your PR by then, I'd have just pointed at that, there's nothing special about A Bug in the context I was using it. [19:36] sounds good! [19:46] ok done with vmware raw userdata review .... looks good enough but minor changes, docs, var/function names to make it a bit more clear what is happening there https://github.com/canonical/cloud-init/pull/691 === hjensas|afk is now known as hjensas === ijohnson|lunch is now known as ijohnson [21:43] blackboxsw: I've pushed to https://github.com/canonical/cloud-init/tree/ubuntu/daily/focal and have seen the daily build get past the previous point of failure: would you mind reviewing what I've done before I move on to other suites, to confirm it matches your expectations? [21:43] blackboxsw: Oops, meant to wait until I'd seen a success to hit send on that; please hold, lol. [21:47] Oh, right, it builds from the LP mirror which hasn't been updated. [22:00] blackboxsw: OK, https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily/+recipebuild/2716114 would have failed by now, so review away! [22:00] Odd_Bloke: looking now [22:03] https://jenkins.ubuntu.com/server/job/cloud-init-github-mirror/399/ has run now? [22:04] blackboxsw: Yep, so my previous build failed because it was still just using the old git repo. [22:06] Odd_Bloke: so the only diff I see after running `git checkout upstream/ubuntu/devel; fix-daily-branch focal upstream;` and the current upstream/ubuntu/devel is here https://paste.ubuntu.com/p/JF9HFhBXW8/ [22:07] Odd_Bloke: so +1 on getting the debian/changelog entry, I think that's what is missing from fix-daily-branch script [22:07] too [22:07] I'm checking the merge order now using ubuntu/focal + ubuntu/daily/focal etc [22:09] and +1 on mergeability and looks like recipe build worked too [22:12] So focal was a _merge_ into the daily branch, because the daily branch was last used for reverting the cherry-picks we performed when we did the feature freeze upload. Other daily branches are just fast-forwarding, because they haven't had any commits applied to them since being refreshed after last time we cherry-picked. [22:12] so that procedure you used should work for any daily branch release [22:13] ahhhh [22:13] So next time I think we'll merge everything. [22:13] +1 thanks for the cleanup here [22:14] so we still need doc update on procedure right? I can chat w/ you at standup to see if this fix-daily-branch tool is warranted, or if we just drop it and make sure docs are up to date [22:28] Yep, we do; I think the tool is probably warranted (this was the simplest case, if we had multiple cherry-picks as we did for the focal release then it would have been easy to miss one). [22:29] And, yeah, we can catch up at stand-up. :)