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