=== ahasenac` is now known as ahasenack === ahasenack is now known as Guest7888 === Guest7888 is now known as ahasenack [18:16] blackboxsw: ok, I've finished ec2 manual tests for 18.2 SRU [18:20] thanks rharper, artful on gce is good, I'll get to xenial just after lunch [18:20] blackboxsw: where do you want me to put the log ? [18:20] MP to the github repo ? [18:43] rharper: ok back from lunch. [18:44] rharper: can you put in in ubuntu-sru: ... https://github.com/cloud-init/ubuntu-sru/blob/master/manual/ec2-sru-18.2-4.txt [18:44] in the manual subdir ec2-sru-.txt [18:49] y [18:54] https://github.com/raharper/ubuntu-sru/pull/1 [19:02] rharper: no need for PR if you want to git push origin master I'm good with that for this repo [19:02] the pr is against your repo, which I can't squash merge to [19:02] blah [19:03] * rharper should stick to the git cli [19:03] ok [19:06] https://github.com/cloud-init/ubuntu-sru/pull/1 [19:06] ok, merged and then PR'd to the base [19:06] I can't write there, so you'll need to merge [19:10] clicked merge button, I'll add your perms if I can [19:13] rharper: you're invited in github to write access on ubuntu-sru [19:14] y [19:14] rharper: added you to github group [19:16] thx [19:21] blackboxsw: thx for merge, now do we also update the desc in the SRU bug, or wait till the end and do that all at once ? [19:21] should I test azure now ? [19:23] rharper: we can just work through ubuntu-sru repo and then all at once attach the files to the SRU bug once we're done [19:23] +1 [19:24] just updated qa-scripts sru-changelog-to-trello to accept num-sections param to allow us to create markdown across multiple sections. [19:26] rharper: I've kicked off an azure xenial test [19:26] nice [19:26] ok [19:26] do we have lxd and nocloud going as well ? [19:26] just waiting on the instance to cume up [19:26] those are run on jenkins right ? [19:26] nocloud-kvm would be helpful to kick off [19:26] in jenkins [19:26] k [19:27] oh, we need to wait for 2.4 to hit -proposed though [19:27] lxc we generally can cut-n-paste from a previous run of our choosing which closely matches our release (tip of master) [19:27] we can't feed a deb to the job [19:27] rharper: it all truth, yes we need to actually truly wait on official -proposed publish of the debs, which won't be until tonight [19:28] ok [19:28] since both were officially approved within the hour [19:28] both == (artful/xenial) [19:28] then I'll hold for now, please ping when I can help start more things [19:28] great thanks rharper, yeah I just wanted a spot check to make sure we don't have to start an SRU-regression on the major cloud [19:28] great thanks rharper, yeah I just wanted a spot check to make sure we don't have to start an SRU-regression on the major clouds [19:28] gotcha [19:33] good work on ec2, just read through logs. yeah I think we should bake in systemd analyze (and cloud-init analyze) into our manual sru tests (and CI per powersj suggestion). we can then at least capture SRU-related differences on each cloud performance. [19:34] I'm adding it to a new sru-templates subdir in ubuntu-sru for each 'manual' cloud. [19:44] upgrade looks fine on azure [19:44] ok capturing logs and simple test cases for reference [19:45] cloud-init analyze blame is nice.... so initial boot on stock cloudimage blames config-disk_setup @ 4 seconds and config-locale @ 3.3 seconds [19:46] that makes up the near half of cloud-init's boot time cost [20:03] blackboxsw: yeah, I think this manual-no-regression sequence can be scripted [20:03] we could use write_files in the initial yaml we pass to generate the file, and then just remotely execute it through the upgrade, and then a post-upgrade-reboot sequence [20:03] +1, we can just contain the basics, only different intial cmdline instance launch and IP obtaining [20:03] y [20:04] I wonder if we should write this as a cloud_test with the ec2 platform [20:06] rharper: that'd be an effective start as we'll have to do something comparable on each platform we add to ci [20:06] * blackboxsw just hadn't spent more than a fleeting glimpse at trying to establish a cloud_test that'll perform the live upgrade test/ post-upgrade-reboot sequence [20:07] yeah, I think we have a reasonable list of "basic" tests here; boot, confirm no tracebacks and status OK, upgrade (via dpkg -i or -proposed); re-run cloud-init init; check status/logs, clean --logs --reboot; wait for boot; repeat [20:07] and add in the collect of systemd-analyze and cloud-init analyze show/blame if we like [20:07] * rharper gives it a go [20:07] I've not tried the ec2 backend in cloud_tests yet [20:08] it's slick. powersj did well [20:08] powersj: is it possible to feed one's on creds in there ? [20:08] rharper: locally yes http://cloudinit.readthedocs.io/en/latest/topics/tests.html#ec2 [20:08] right [20:08] if I launch it myself (vs on jenkins) [20:09] correct, I don't want jenkins knowing any of our stuff [20:09] perfect! [21:21] ok just pushed ubuntu-sru with doc output from create-sru.py. [21:25] ok, now onto SRU validation script writing for the 24 related bugs (most of them should be covered in part by our manual tests). [22:17] rharper: can you rebase https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438 for ci to work [22:17] everything is done there right? [22:39] minor fix for tools/make-tarball to fix nacc's discoveries during the test/upload process. [22:39] https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342761 [22:39] I didn't want to lose that fix changeset [22:53] blackboxsw: sure