[02:08] ckonstanski: reviewed your two MP, i'll grab those tomorrow. [02:09] note my updates to commit messages we'll use those. I realize they're long windeded for the changes but i like to read git logs (yeah, i'm that nerdy). [02:09] also, LP: #XXXXX [02:09] is the way you reference a bug. [02:09] Thanks! [02:20] Will do. At Charter se used Issue: #xxxxx. In Openstack it's Closes-Bug: xxxxx. One more to learn. [02:27] The perfect couple of bugs to learn the ropes. [15:11] smoser: here is the merge https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/331736 [15:11] blackboxsw: ^ [15:19] https://bugs.launchpad.net/cloud-init/+bug/1725067 [15:19] Ubuntu bug 1725067 in cloud-init (Ubuntu Artful) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Fix committed] [15:19] so this is the bug I think we expect foundations to approve [16:26] hrm smoser rharper https://launchpad.net/cloud-init/+packages shows cloud-init for artful at rev 17.1-25-g17a15f9e-0ubuntu1~17.10.1 yes apt update/apt policy on artful still shows only 17.1-18-gd4f70470-0ubuntu1 [16:27] what 'else' do we wait for before we can see a published package version via apt repos once an SRU has landed? [16:27] blackboxsw: it's in artful-proposed [16:27] pending-sru.html still shows the cloud-init package in pending status for artful [16:27] (per rmadison) [16:27] nacc right, but once we pass SRU, doesn't it move to artful-updates? [16:27] [16:28] blackboxsw: after 7 days [16:28] ahhh [16:28] blackboxsw: depending on the package, there are exceptions, but usally there is a back period to flush out regressiosn [16:28] was missing "what else needs doing" there. Answer:patience child, good things come to those who wait [16:29] thx nacc makes sense [16:29] blackboxsw: http://people.canonical.com/~ubuntu-archive/pending-sru.html [16:29] blackboxsw: it's pending still, but green on bugs meaning all are verified [16:29] yeah that is still sitting in artful (all green) [16:29] yeah [16:30] didn't know if there was another button/person I needed to push (as the artful bugs themselves have been commented by landscape janitor as uploaded [16:30] yep [18:16] blackboxsw and powersj http://paste.ubuntu.com/25825019/ [18:16] that is what i have run/am-running fro nocloud tests. and will post to the bugs. [18:16] bug [18:18] smoser: that looks good [18:18] * blackboxsw likes it. I'm reviewing powersj kvm branch [18:19] I find myself wanting a make target for running out integration tests in general so I don't have to lookup what we are running from jenkins [18:19] yeah. something needs easier-ing [18:21] blackboxsw: so like a --proposed and it just does the right thing? [18:27] powersj: yeah like that, I just want to document it somewhere in cloud-init src proper. [18:27] blackboxsw: https://cloudinit.readthedocs.io/en/latest/topics/tests.html [18:27] that page would be a good place for it [18:27] Have an example runs [18:27] can put what we do for nightly testing + proposed testing + ci [19:39] rharper: so.. looking at cyphermox's image [19:39] y [19:40] crazy. if i enable debug logging to the console (change 'WARNING' to 'DEBUG' in the stderr logger in /etc/cloud/cloud.cfg.d/05_logging.cfg) [19:40] then ENOREPRODUCE [19:40] hrm [19:40] but by default, it reproduces ;) [19:40] doesn't change the logging [19:40] and if you just remove the import random from util.py in your image [19:40] what happens ? [19:41] apparently writing stuff to the console constitues entropy [19:41] i'll try that. [19:41] smoser: oh, hold on [19:41] oh, yeah [19:41] for sure [19:41] console data [19:41] smoser: if you boot once and the reboot you won't necessarily get the same result [19:41] i'm not booting. [19:41] mounting, changin file, unmounting booting. [19:41] fair enough [19:42] do we have the KCONFIG delta ? [19:43] you'll have to ask kamal for that [19:43] doesn't the image have the config-X file in /boot ? [19:43] that's enough then we can diff from some other image [19:43] removing 'import random' didnt help [19:44] rharper: what are you looking for? [19:44] delta [19:44] presumably for something in particular [19:44] not yet [19:44] # pastebinit /boot/config-4.4.0-1009-kvm [19:44] http://paste.ubuntu.com/25825393/ [19:47] $ diff -u config-4.4.0-59-generic config-4.4.0-1009-kvm | pastebinit -f diff [19:47] http://paste.ubuntu.com/25825403/ [19:52] no CONFIG_USER_NS ? aren't the minumals used for containers ? [20:12] powersj: how'd you setup /srv/citest/nocloud-kvm for integration test runs? [20:12] I'm trying to run your nocloud-kvm branch [20:12] mkdir -p /srv/citest/; chown -R jenkins:jenkins /srv/citest [20:12] something like that... [20:13] kk thx. just trying to document shortcomings on a fresh artful install [20:13] basically make sure you own that dir [20:13] :) [20:13] thx [20:13] np [20:13] artful! [20:13] did you upgrade? [20:13] my desktop is artful, laptop1 xenial laptop2 zesty [20:13] :) [20:14] want to play w/ all the pretty ponies [20:15] hi team. [20:18] hi sedition [20:19] y'all are always working hard. one of the most active channels i'm in. [20:22] :) maybe we type too much in IRC :) [20:22] no such thing. i've been an irc junkie for too long [20:22] heh [20:23] i've really been digging cloud-init so i figured i would idle and watch [20:24] that's nice to hear. File bugs/comments/code etc if you find features you think are needed etc. we have that status meeting Monday where we brain dump what we've been working toward. You are welcome to raise questions concerns there too if there are things you are itching to discuss with a broader audience [20:25] reminds me I need to update the topic === blackboxsw changed the topic of #cloud-init to: is Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 10/30 16:00 UTC | cloud-init 17.1 released [20:25] ok great! i can do that. [20:25] so Monday 16:00 UTC there are a few more eyes on this channel [20:25] :) [20:25] should be every 2 weeks [20:29] grr and I need to publish last meeting logs to the github.io page. [20:57] Hi all, I am trying to figure out the appropriate incantation to get cloud-init to run multiple commands via pipes while sudo'd to a user. The following works just fine when done as root: " gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export" When I try to invoke it via sudo -u -i user however it simply ignores the entire list of runcmd directives. [20:57] sudo -u user -i that is... [20:58] I've also tried sudo -u user -i sh -c which works on the command line but not via cloud-init. [21:01] Am I relegated to making this a script or something? [21:06] hrm [21:07] blkadder: do you have a paste of your runcmd yaml ? [21:07] Yes, but I have been fiddling with it endlessly to try to get it to work. [21:08] How should I post it? [21:08] It's just the one line that is causing problems... [21:08] If I comment it out everything else works. [21:08] And if I do it all as root (no sudo) it all works... [21:10] yeah, just runcmd: and the lines that don't work [21:10] we can generally replace the gpg and stuff with piped echos and greps just to simulate the pipes [21:10] also your cloud-init.log may be helpful in case there's something else going on [21:11] - sudo -u jenkins "gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export" [21:11] That was one invocation. [21:11] k [21:11] I have also tried with - sudo -i -u jenkins [21:12] And even sudo -i -u jenkins sh -c "...foo..." [21:19] try this [21:19] - [sudo, -u, jenkins, "gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export"] [21:19] Will do, thanks. [21:19] that gets put into the shell'fied config in /var/lib/cloud/instance/scripts/* so you can see the script format there; possible run it by hand in the instance to see if there are other errors [21:20] root@a1:/var/lib/cloud/instance/scripts# cat runcmd [21:20] #!/bin/sh [21:20] 'sudo' '-u' 'jenkins' 'gpg --list-keys --with-colons | grep sub | awk -F: '\''{print $5}'\'' | gpg --armor --output /repo/qbis-repo.gpg.pub --export' [21:21] That's interesting... [21:21] That invocation creates a shell script? [21:22] runcmd elements get shellified [21:22] that was the latest cloud-init; possible the older versions just exec them; [21:22] * rharper reads the docs and code [21:23] That worked, thanks. [21:23] I am doing my best to read docs and googling before bugging the channel. :-) [21:23] My google fu failed on this particular nuance. [21:23] no [21:23] I know it changed [21:24] Ahh. ok. [21:24] so the string is execve'd [21:24] the list is shellified [21:24] Oh no it didn't quite work. [21:24] The parser works now but... [21:24] sudo: gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export: command not found [21:25] Before it wasn't even parsing the yaml blob (errored in logs) [21:25] yea, I can see that, lemme play with the escaping [21:26] asking in channel is fine. it helps us know the probs people are hitting. (and it helps me learn from rharper/smoser) [21:26] Ok good deal, just didn't want to bother with noob questions... [21:28] ok, try this [21:29] - [sudo, -u, jenkins, --, "gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export"] [21:29] Ok, one sec. [21:29] the -- tells sudo that it doesn't have any more argument parsing to do [21:30] Thanks for the info I was wondering... [21:33] rharper: I also just validated pipes in general in runcmd with this [21:33] cat runcmd_pipes.yml [21:33] #cloud-config [21:33] runcmd: [21:33] - cat /etc/os-release | grep CODE > /tmp/cloud-init-output [21:34] no quotes etc worked for me (I know blkadder's using single quotes etc on a more complex command). [21:34] well, the real trick is knowing that the - [run, my, cmd] gets shellified, which makes | easy [21:34] otherwise you need the exec'ed command to invoke a shell for you sudo -u jenkins -- sh -c 'do this | eat that | write here' [21:34] The pipes work fine, it's the sudo that seems to cause issues... [21:35] If I run that same command that I posted previously as root, no problem. [21:35] right, you're in a shell [21:35] vs. exec, which expects a binary [21:35] Same result rharper... [21:35] no dice, huh; I don't get that --export command not found [21:35] Let me double check my yaml file [21:36] - [sudo, -u, jenkins, --, "gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export"] [21:37] I think I answered my own question; you're sudo'ing to jekins to dump the keys, and then running the rest of that as non-jenkins [21:37] Ahh, I want to run it all as jenkins. :-) [21:37] ok, that makes it easier [21:37] we'll have sudo run a shell as jenkins [21:38] I tried that. [21:38] But you have a smarter way I am sure. [21:38] I tried sudo -i -u jenkins sh -c ... [21:38] the trouble you'll have is that you can't write to /root as jenkins [21:39] I don't want to. [21:39] Am I missing something? [21:39] I am writing to /repo [21:39] Which is owned by jenkins. [21:39] oh, right [21:39] that was a local error [21:39] I don't have a jenkins, so I'm subbing something else [21:39] Ahh [21:40] - [sudo, -u, jenkins, sh, -c, "gpg --list-keys --with-colons | grep sub | awk -F: '{print $5}' | gpg --armor --output /repo/qbis-repo.gpg.pub --export"] [21:40] I replaced jenkins with ubuntu; but running that gets me gpg running and no complaint about export commnd [21:41] Hmm... [21:41] Let me give 'er a shot.. [21:46] And we have key! [21:46] Thanks! [21:47] \o/ [21:48] :) [21:48] blkadder: thanks for stopping by =) [21:48] So on a side note would you be willing to explain the difference in invocation method? [21:48] yeah [21:48] I tried sudo -u -i jenkins sh -c which did not work. [21:48] you had -i [21:48] which does the login shell [21:48] Right. [21:49] which I didn't try; but resets the env and other things [21:49] but, you also didnt use the [, list ] method [21:49] I did not. [21:49] IIURC [21:49] so, cloud-init attempted to exec("string") [21:49] I have used it elsewhere. [21:50] I suppose that should work if quoting and all were correct [21:50] That's what I am getting hung up on... Works fine on command line but not via cloud-init [21:52] if you have logs of the failure (/var/log/cloud-init*.log ) I might be able to see what went wrong [21:52] Well, I can certainly reproduce if it is helpful. [21:53] Not a huge deal since I have a working solution, but just more curious why what works on the command line doesn't work the same... [21:54] well, I think it was the quoting since your were getting yaml parsing errors [21:54] Ack. [21:55] http://paste.ubuntu.com/25825970/ [21:55] you can try that [21:56] using the | to let you inline the command as a string [21:56] Ahh, cool. [22:00] Now to figure out why I am seeing read errors in the log... [22:01] Thanks again rharper. [22:01] np [22:20] powersj: minor comment on https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/331736 [22:20] blackboxsw: re: tox, correct we pulled that in on a different commit, but that is in master [22:21] https://github.com/cloud-init/cloud-init/commit/aa024e331f8196855fa8d707a2dd7e26e1deab40 [22:21] ok yeah I didn't recal until I saw it working on my other master checkout [22:22] blackboxsw: what do you think about the use of /tmp [22:22] powersj: as mentioned inline. use /var/tmp instead [22:22] it doesn't get clobbered as frequently [22:22] by systemd [22:24] it's what cloud-init does too for anything we write out that needs to be somewhat persistent [22:24] *sigh* [22:24] ok :) [22:25] though I don't think it should really affect these tests, best to get rid of any known intermittent failure conditions as that's been the bane of our existing with CI in the last couple weeks [22:25] s/in the last/over the last/ [22:25] why do we need persistence of files in tmp? [22:25] I feel that this should be equally documented then [22:25] by *our* I mean you and rharper [22:25] past a run that is 1 hour long [22:26] powersj: yeah want me to add it to readthedocs? like runcmd? or write_files ? [22:26] I don't think so [22:26] it's not a cloud-init specific thing [22:26] like a Note: don't write to /tmp because of https://bugs.launchpad.net/cloud-init/+bug/1707222? [22:26] Ubuntu bug 1707222 in cloud-init (Ubuntu) "usage of /tmp during boot is not safe due to systemd-tmpfiles-clean" [High,Fix released] [22:27] dpb1: how else would an end user know about this? I get that maybe it isn't a cloud-init only thing [22:27] hm [22:27] because of the after= before= [22:28] as an end user writting user-data I'm not sure I'd ever see that... [22:28] ok [22:28] guess so [22:28] strike my comments [22:28] yes, we should put it on readthedocs [22:28] and yes, powersj should fix his branch [22:28] it's likely because cloud-init is so early in the boot process we are hit by this more than anywhere else [22:28] :) I will [22:28] also, I think we probably shouldn't have examples that use this [22:29] yup [22:29] like https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd [22:29] blackboxsw: new bug would be fair [22:29] wget, "http://example.org", -O, /tmp/index.html [22:29] yeah will add it and can clean up docs [22:29] add it and own it [22:32] https://bugs.launchpad.net/cloud-init/+bug/1727876 [22:32] Ubuntu bug 1727876 in cloud-init "Document in RTD that cloud-init can't write to /tmp due races with systemd LP:1707222" [Medium,Triaged] [22:40] blackboxsw: thx for review I'll make changes and let you know when they are up