[18:25] powersj: https://jenkins.ubuntu.com/server/job/cloud-init-ci/20/consoleText too many values to unpack? [18:30] hmm a merge on ubuntu/xenial [18:30] let me see what the state of the integration tests is there [18:33] powersj, yeah, was justa about to ask about that [18:33] if i cherry picked your integration fixes [18:34] would that do it ? [18:35] Yes it would. It is due to the new test framework handling error exceptions from pylxd which is missing from the old version [18:46] ok. i'm going to attempt to pull those along [19:09] powersj, bah [19:09] so i got those commits. and didn't fix. [19:09] so i'm going to drop them again and ignore the failure. [19:09] :-( [19:09] ok [19:09] same failure though? [19:09] i grabbed the commits, but they're not in the tree [19:09] yeah [19:10] https://jenkins.ubuntu.com/server/job/cloud-init-ci/21/console [19:10] they're not in the tree, they're in quilt patches in debian/patches [19:10] ah [19:10] so you'd have to 'quilt push' in order to run the intergration tests with them there. [19:12] hmm should I keep the integration tests as a part of CI then? [19:15] yes [19:15] and msot of the time this would work. [19:17] ok as long as you are fine with those odd ball cases :) === Guest28796 is now known as mgagne [19:35] powersj, i wonder... [19:35] i dont have a suffiecntly old lxd anywhere [19:35] ? [19:35] could you easily run integration tests on the xenial deb in https://launchpad.net/~smoser/+archive/ubuntu/cloud-init-dev/+files/cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2~ppa3_all.deb [19:39] we could; clone master to get latest tests, and pass --deb option to integration tests to put that deb into the images. [19:39] this however, assumes we don't run into a mismatch of tests and features/functionality [19:44] getting the tests executed will be step 1 [19:44] instead of failure to launch [19:46] powersj, yeah. i was just asking if you could do it locally [19:48] smoser: running... [19:48] i think it will run [19:49] oh it is [19:49] collecting output for tests now [20:03] tests passed [20:37] https://paste.ubuntu.com/24975100/ [20:50] hmm CI doesn't seem to be triggering at the moment now... [20:53] powersj: attach those results to the MP? [20:56] dpb1: done [20:57] thx [21:00] ok CI is back, sorry about that folks [21:27] [ubuntu/xenial-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 (Waiting for approval) [21:27] [ubuntu/yakkety-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.10.2 (Waiting for approval) [21:27] woop dee doo [21:27] [ubuntu/zesty-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~17.04.2 (Waiting for approval) [21:31] night night [21:31] smoser: cya [21:56] rharper: this should be fix released? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1693939 (for cloud-init project) [21:56] Ubuntu bug 1693939 in cloud-init (Ubuntu Zesty) "Switch Azure detection to use chassis_asset_tag" [Medium,Confirmed] [21:56] dpb1: hrm [21:57] * rharper checks in zesty daily [21:57] well [21:57] dpb1: no, I don't think so [21:57] I mean, the cloud-init project bug [21:57] er [21:57] task [21:57] 0.7.9-113 is in zesty, so ideally we'd SRU to Zesty [21:57] not the source package task [21:57] ok [21:58] that confuses me [21:58] why [21:58] ? [21:58] we don't strictly have to update zesty [21:58] but it's not nice to have 16.04 up to date but the current release have issues [21:58] why is zesty involved in the cloud-init project task though [21:59] there is a separate source package task on there [21:59] well, we upload to each of the current release (devel + any currently supported releases) [21:59] possibly as cloud-init has a branch per release to handle the packaging ? [21:59] I don't know for sure [21:59] ok [21:59] the release process stuff is a bit hazy to me [22:00] I'm not too keen on the lp bits, but I do know that we have a branch per release for packaging changes [22:00] in our source tree (outside of the ubuntu distro) [22:00] yes [22:00] git [22:00] k [22:00] that makes sense [22:01] I'll ask scott when I next think of it. [22:01] ok