[01:39] Trying to bust out the two easy issues now. I created a launchpad bug for the rc-service one. How do I assign it to myself? Or do I not do that? (This is where I learn the procedures around launchpad) [01:54] Pushed commits for issues 1727121 and 1727126 [01:55] A brreakdown in the "hacking" instrucitons. Will catch up tomorrow. [02:31] cool [02:31] I made https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/332754 , but I'd rather just use yours [02:34] ckonstanski: all you should need to do is go to your fork/branch and click the merge this button [03:18] target reference path? master? [03:20] found it in "hacking" -- master [03:21] done [12:14] ckonstanski: cool, link? [14:32] http://cloudinit.readthedocs.io/en/latest/topics/hacking.html [14:51] ckonstanski: sorry, to your merge request :P [14:54] https://code.launchpad.net/~ckonstanski/cloud-init/+git/cloud-init/+merge/332755 [14:54] https://code.launchpad.net/~ckonstanski/cloud-init/+git/cloud-init/+merge/332756 [14:54] 2 different ones [15:14] ckonstanski: prometheanfire i've seen your bugs and mp... i do want to review for you. [15:14] just time and such. but we'll try to get some feedback today. [15:18] smoser: sure, don't need to do mine, do ckonstanski's [15:46] removed (deleted) [16:07] smoser: your update looks good, however I am unsure about the variable substitution into the shell script [16:08] when it generates the xml right now it produces "release={release} [16:08] triggerwhat={triggerwhat}" [16:08] which isn't what we want I think [16:08] hm.. [16:09] powersj: i was trying ot generate the xml locally [16:09] This is why there was lots of copy and pasting... I always got frustrated with this [16:09] but dont know how ? [16:09] if i run './test-jenkins-jobs' locally, it ends up i think trying to post xml [16:09] (and failing reasonably) [16:09] the test-jenkins-jobs will run "jenkins-jobs test " [16:10] yeah, but lcoally [16:10] and if it produces XML without any exception, then it means the job at least generated [16:10] that is all local [16:10] won't try to push anything or update the jenkins as there are no creds in that repo :) [16:10] http://paste.ubuntu.com/25817851/ [16:11] that is on master (with jenkins-jobs installed from archive) [16:11] what is your version of jenkins-job-builder? because I am using pipelines it has to be a certain version [16:11] yeah the archive version won't work [16:12] if you look at the readme or travis file you will see I have ot use: jenkins-job-builder==2.0.0.0b2 [16:18] powersj: pip install jenkins-job-builder just got me 1.6.2 [16:18] ckonstanski@sphinkpad:~/jobs/talligent/projects/openbook-v4-ci/jjb $ cat requirements.txt [16:18] jenkins-job-builder>=2.0.0.0b2 [16:18] [16:18] That'll git er [16:19] smoser: yeah if you add the >= or == with version it'll do it [16:31] powersj: :-( [16:31] why is my macro not expanding [16:40] powersj: http://paste.ubuntu.com/25817997/ [16:40] "yaml is hard" [16:41] HAHAHAHA [16:41] started with 'foo.yaml' like rthis [16:41] http://paste.ubuntu.com/25818005/ [16:41] and iterated [16:43] that looks good [16:43] powersj: i'm not sure if i have the 'artifacts' right though [16:43] what adds the 'cloud-init/' that you have in cloud-init/integration.yaml [16:43] - archive: [16:43] artifacts: 'cloud-init/results/**' [16:43] the git clone [16:44] clone's into cloud-init [16:44] got it. thanks. [16:44] so $WORKSPACE/cloud-init [16:52] smoser: any reason to not merge? [16:52] looks good on my end [16:53] powersj: go for it. [16:54] Is cloud-init an openstack project? Need to know for a question asked at work. [17:01] ckonstanski: we are not, smoser could give better history though [17:01] smoser: jobs deployed, looks good! thank you :D [17:03] ckonstanski: cloud-init 2.0 kind of started as a openstack project, but that work was shelved, to rather continue development on 1.0 [17:27] powersj: i'm going to hit 'build-now' [17:28] https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-integration-proposed-x/ [17:28] smoser: go for it [17:29] ckonstanski: it's not, just heavilly used by images running on openstack [17:47] powersj: https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-integration-proposed-x/80/console :-( [17:47] AssertionError: '0.cloud-init.mypool' not found in '' [17:47] FAIL: test_ntpq_servers (tests.cloud_tests.testcases.modules.ntp_pools.TestNtpPools) [17:47] ugh. how the $*(# did that fail [17:47] love this new output btw... thanks :) [17:48] while 79 passed [17:48] modules/ntp_pools [17:49] uhh hold on [17:49] it built the deb.... [17:49] something may have changed when I merged your jenkins job... doesn't look like it is doing the pull-lp-source cloud-init xenial-proposed [17:50] oh? did i foobar that ? [17:50] oh your builder is wrong [17:50] review fail on my part [17:50] see I trust you too much ;) [17:50] i grabbed the wrong code block [17:50] phft [18:00] powersj: mp coming . sorry. [18:00] no worries, I feel bad for missing it in the review [18:11] powersj: the start dir of a job [18:11] isnt it going to be the work dir ? [18:11] ie, a base, clean dir ? [18:13] smoser: I don't believe so [18:13] that's why I have rm everywhere [18:13] doesnt taht seem scary and silly ? [18:13] ie, what would be in a directory if it was not empty ? [18:13] only another jobs data [18:14] which we are going to remove ? [18:14] it is scary :) [18:14] hence the rm -rf * [18:15] https://stackoverflow.com/questions/24412418/whats-the-working-directory-in-jenkins-after-executing-a-shell-command-box [18:15] Building remotely on torkoal (metal-amd64) in workspace /var/lib/jenkins/slaves/torkoal/workspace/cloud-init-integration-proposed-x [18:17] doesnt it seem completely broken ? [18:21] that seems to be talking about multiple build steps, which may treat it differently I haven't played with that though [18:23] hence why folks ask about cleaning up the workspace: https://stackoverflow.com/questions/28683914/is-there-any-way-to-cleanup-jenkins-workspace [18:24] powersj do you get hwat i'm saying ? [18:24] ah. ok. i get it. [18:24] I do, but I'm not sure if you are implying that Jenkins should be cleaning it up for us and we should not be doing the rm or something else [18:24] you can't run a job twice at the same time. [18:25] that is correct [18:25] ok. [18:32] powersj: https://github.com/canonical-server/jenkins-jobs/pull/15 [18:34] smoser: I like what you did there [18:37] powersj: how quick does it go live ? [18:37] smoser: it is live now [18:38] smoser: update jobs every 15mins, I just kicked it though to get it live [18:41] k [18:41] * smoser build-nows [18:42] oh fudge [18:44] :-( https://github.com/canonical-server/jenkins-jobs/pull/16 [18:49] smoser: accepted and jobs updated [19:10] smoser: all looks good now? [19:10] yeah. \o/ [19:10] :) [19:11] now some day, clean up all the other jobs. [19:11] x ran, i pushed 'go' on 'z' [19:11] yeah [19:11] and then will do on 'a' [19:11] * smoser will try to script somthing like i suggested to grab results and put them on a bug.\ [19:11] blackboxsw: ^ [19:12] blackboxsw: did you manually do all those bug updates ? [19:12] smoser: yeah I'm wrapping up each test (I was missing some it looked like) [19:12] jsonschema warning->debug is last [19:12] then I think we are good [19:12] lemme push [19:13] I manually added SRU verification logs to our existing ubuntu-sru/bugs* [19:14] smoser: pushed b0b83fc0e659f3e30f948ef0b9a63df14054aca8 to ubuntu-sru [19:15] I've manually separated the verification results content and added it to the bug as I've untagged the verification-needed ->done switches [19:16] but left the script/results as one file in ubuntu-sru [19:16] we could separate easily if you wanted so it's easier to add results to bugs as a comment [19:18] last one to validate here http://pad.lv/#1724354 [19:20] blackboxsw: i'm pretty sure you can do this: [19:20] http://paste.ubuntu.com/25818813/ [19:22] +1 smoser [20:09] ok pushed and included ryan's sru info for https://launchpadlibrarian.net/341226002/1718287.log [20:25] blackboxsw: fyi https://bugs.launchpad.net/cloud-init/+bug/1727358 [20:25] Ubuntu bug 1727358 in cloud-init (Ubuntu) "cloud-init is slow to complete init on minimized images" [Undecided,Incomplete] [20:27] hrm from sru validation run on 17.1? [20:27] no. [20:28] from cyphermox reported yesterday. [20:28] i have to run :-( [20:28] should get actual cloud-init analyze output [20:28] it wont help much [20:28] the 120 seconds is lost in that one line of debug [20:28] ah [20:28] so he already did the analyze part ;) [20:28] i have to run, we have successful integration-proposed-x z a [20:29] woohoo [20:29] well, i did [20:29] * powersj should now go read it [20:29] so we should copy those and attach to the sru bug [20:29] i can do that later, but have to run now. [20:36] hey folks [20:39] cloud-init 0.7.5 on ubuntu 14.04 doesn't understand the apt: proxy: value, instead it wants apt_proxy. I asked for help with lxc and they told me to report this for cloud-init. I can file a Launchpad bug if you like. [20:39] https://github.com/lxc/lxd/issues/3975 [20:54] roadmr: file a bug please [20:55] dpb1: will do! [20:55] dpb1: https://bugs.launchpad.net/cloud-init, right? [20:55] yeah hrm roadmr I think it's worth a bug, I'm not sure if cloud-init 17.1 would support the same cloud-config keys back in 0.7.5 but it's worth a bug so we discuss and document whether or not we'll backport that cloud-config [20:55] yeah roadmr [20:55] https://bugs.launchpad.net/cloud-init/+filebug [20:55] blackboxsw: right, we will want to make our stance clear in the bug either way [21:06] https://bugs.launchpad.net/cloud-init/+bug/1727527 [21:06] Ubuntu bug 1727527 in cloud-init "cloud-init 0.7.5 doesn't honor the apt: proxy: setting, needs apt_proxy instead" [Undecided,New] [21:06] the alternate solution works fwiw, so it doesn't seem horrible, but it would be nice if it were documented :) [21:07] thanks for the bug [21:14] np :)