[15:17] I want to execute a post-initiation piece of user-data. I tried adding the data to /var/lib/cloud-scripts/per-boot but the script fails. What should that script look like? [15:24] http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot [15:30] rharper: I tried that, but seeing an error in cloud-init.log. Here's the script: http://pastebin.ubuntu.com/23480882/ [15:31] and the relevant log: http://pastebin.ubuntu.com/23480880/ [15:33] aisrael: and the first paste is the contents of that 99-test ? [15:33] rharper: Correct [15:33] well, it says: [15:33] ['/var/lib/cloud/scripts/per-boot/99-test']#012Exit code: -#012Reason: [Errno 8] Exec format error#012Stdout: ''#012Stderr: '' [15:33] oh. yeah. so aisrael if you want to just execute something per boot [15:34] the things in that dir need to be executable [15:34] they're things to execute, not cloud-config [15:34] aisrael: if you use runcmd, it's exec directly from cloud-init. vs. adding a file to that dir [15:34] what I suggested is different than writing files to per-boot dir [15:36] smoser: Is there a way to run a bit of cloud-config on every boot? For background, I'm writing a cloud-init charm layer, where the underlying machine has been pre-allocated (think manual provider) [15:38] you can change the runcmd to run every boot. the thing that stinks about doing that is that you have to re-define all of 'cloud_final_modules' (see /etc/cloud/cloud.cfg) in order to modify the frequency of scripts-user [15:40] smoser: ok, supposing I did that ([scripts-user, always]), would I then put that cloud-config into /etc/cloud/cloud.cfg.d? [15:40] http://paste.ubuntu.com/23480925/ [15:41] you can put it in user-data, or you can modify the file in /etc/cloud/cloud.cfg or add it to a file in that dir. [15:41] aisrael: fwiw, your examine with runcmd works fine on a new instance; I think your failure was related to the modifications of files in the local per-boot dir [15:42] right. [15:42] aisrael, you can also use write_files to put something into /var/lib/cloud-scripts/per-boot [15:42] and that thing that you write there will run once per boot [15:43] that seems best [15:44] aisrael, http://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files [15:48] Ok, let me see if I can get this working via cloud.cfg. It's not writing files, per se, that I need but to inject custom cloud-config into an already bootstrapped instance. [15:50] aisrael, oh. well, that will be more difficult. [16:08] smoser: rharper: Thanks for the info! I'm not sure what my path forward on this will be, but I have a clearer idea now. [16:09] aisrael, you can 'cloud-init single --frequency=always --name=' [16:09] but you have to know what that-name is. ie, which cloud-initmodules will need tob e run for your config. [16:10] smoser: ok, that makes sense [19:14] rharper, [19:14] http://pad.ubuntu.com/tMdgYGEvgL [19:14] look at the bold [19:14] * rharper looks [19:14] i'm not sure if we want Before=basic.target there. [19:15] versus before=sysinit.target [19:15] hrm [19:15] lemme look at my yakkety instance [19:15] pitti reviewed that and acked it at https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547 [19:16] you have Before=basic.target twice [19:16] line 24 and 26/27 [19:18] http://paste.ubuntu.com/23481950/ [19:18] smoser: I think looking at that, basic.target is too late [19:19] rharper, its not twice. where do you see that ? [19:19] I mentioned the lines [19:20] - add Before=basic.target (**wonder if this is right**) [19:20] - add Before=basic.target [19:20] this is done to become part of "early boot" in order to to be able to affect mounts (http://pad.lv/1611074) [19:20] oh. in the pad. [19:20] yes [19:20] sorry [19:21] i thought you mean tin the .service [19:21] adjusted the pad [19:21] so, the -replace 'Wants'/After local-fs.target with 'systemd-remounte-fs.service' is much earlier [19:21] if local-fs.target is good enough? why would we wait longer ? [19:22] we dont wait longer. [19:22] we are now running earlier (possibly) [19:22] after local-fs.target would possibly include all the local systemd generated .mount [19:23] which we have to run before [19:24] i think its right. [19:25] smoser: so, Xenial without the SRU is running *too late* for mount; what did we put in Yakkety ? Before=local-fs.target ? and slangasek suggests systemd-remount-fs.service ? [19:26] slangasek saw what he believed was a loop [19:26] smoser: I'm confused between what we did in yakkety, vs. where Xenial is at (I'm ignoreing where Xenial is at, and interested in changes to cloud-init trunk to understand the changes; then we can look at the Xenial -> SRU changes [19:26] but not one i'd seen in practice. [19:26] * rharper looks a this cloud-init-loca.service now [19:26] sure. thats fine. thats ultimately what we're doing. [19:26] the Wants=local-fs.target with an After=local-fs.target [19:27] is what we have in yakkety now [19:27] for cloud-init-local.service [19:27] that *functions* for early mount [19:27] and slangasek suggests that makes a loop or something like that ? [19:27] right. [19:27] well, he did. [19:27] Im not seeing it either [19:28] which is why i dropped the local-fs stuff [19:28] i'm not sure it is or not [19:28] but essentially saying : After=local-fs.target [19:28] *and* [19:28] it seems we need a Before=sysinit.target *AND* a After=systemd-remount-fs.service [19:28] maybe that RequiresMountsFor does the trick [19:28] no. [19:28] shoot. [19:29] so... we drop the local-fs.target [19:29] as we dont need that and because we're writing things to /etc/fstab, it seems like there could be a loop there. [19:29] as we say that those mounts should not be processed untill after cloud-init.service [19:30] ahh [19:30] I see [19:30] but we said cloud-init.service should be after local-fs.target (which would include them) [19:30] it seems reasonable [19:30] yes [19:30] but i'd never seen it [19:30] oddly neither have I [19:30] and there's no complains [19:30] no 'break's or complaints or anything [19:30] complaints from journalctl [19:30] right [19:30] so i suspect that sytemd resolved it elsewhere [19:30] probably by adjusting the .mount things [19:30] well [19:30] clearly from the chain, local-fs.target is *reached* prior to cloud-init-local running [19:31] and trivially cloud-init.service [19:31] i assume it changed the meaning of local-fs.target [19:31] so it must not be a hard requirement w.r.t fstab writing [19:31] so at the moment i think that Before=basic.target is ok, [19:32] at least i dont have any fallout of that that i'm aware of [19:32] it's clearly OK, as basic.target is much later [19:32] i think i'll prepare sru with it as it is in zesty [19:32] the question is whether we want to ensure we run even earlier [19:32] much later than waht ? [19:32] say Before=sysinit.target [19:32] or local-fs.target [19:33] yeah, so i suspect that cloud-init.services 'Before=basic.target' ends up not doing anything [19:33] smoser: so, I think we have to be after local-fs.target in that, we can't assume we can write to /etc/fstab unless we have local-fs.target, right ? [19:33] shoot [19:33] yeah, so i suspect that cloud-init-local.service 'Before=basic.target' ends up not doing anything [19:34] as cloud-init.service is Before=sysinit.target and After=cloud-init-local.service [19:34] well, it's before it, but that's not really making it run "early" [19:34] so cloud-init-local.service gets forced early due to cloud-init.service's Before=sysinit.target [19:34] so i think this is fine. [19:38] smoser: we might want to do an in HO with slangasek in a bit [19:38] :) [19:38] +1 [19:38] I think cloud-init-local.service should be explicit [19:46] rharper, yes, we should change it , but it does not actually change anything [19:46] added https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310919 [19:48] smoser: yes [20:44] smoser: ping re: set_hostname vs change_hostname [20:44] err s/change/update/ [20:44] powersj, thinking [20:46] ok. so [20:46] update_hostname runs PER_ALWAYS (every boot) [20:46] (more coming) [21:03] powersj, http://pad.ubuntu.com/NtJAvEJEiJ [21:07] smoser: thank you. Let me think about that and implications with testing them [21:43] harlowja: around? question re: cc_ssh_authkey_fingerprints [22:11] rharper, http://paste.ubuntu.com/23482707/ [22:11] does that seems right ? [22:11] systemd-networkd.service is After dbus.target should say After=dbus.service [22:12] and sysinit.target is before dbus.service; hence the loop [22:13] dbus.service which runs after sysinit.target, but cloud-init.service is Before=sysinit.target [22:13] smoser: and the last paragraph is spot-on [22:15] rharper, fixing [22:31] * rharper relocates home [22:46] question. Does cloud-init automatically resize the root partition to the size of the image? Say i download a cloud image that is 2gb max size, i do qemu-img resize img.img 50G, making it 50G now, when it first boots using the cloud-init iso will the root partition autoresize to 50G/ [23:00] vans163: I think so... take a look at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resizefs [23:04] powersj: ty guessing default may not be true [23:54] vans163, yes. [23:54] was it not doing that ? [23:55] you can tell it not to. but generally thats the desired behavior