[15:17] <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:24] <rharper> http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot
[15:30] <aisrael> rharper: I tried that, but seeing an error in cloud-init.log. Here's the script: http://pastebin.ubuntu.com/23480882/
[15:31] <aisrael> and the relevant log: http://pastebin.ubuntu.com/23480880/
[15:33] <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:34] <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:36] <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:38] <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:40] <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:41] <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:42] <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:43] <rharper> that seems best
[15:44] <smoser> aisrael, http://cloudinit.readthedocs.io/en/latest/topics/modules.html#write-files
[15:48] <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:50] <smoser> aisrael, oh. well, that will be more difficult.
[16:08] <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:09] <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:10] <aisrael> smoser: ok, that makes sense
[19:14] <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:15] <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:16] <rharper> you have Before=basic.target twice
[19:16] <rharper> line 24 and 26/27
[19:18] <rharper> http://paste.ubuntu.com/23481950/
[19:18] <rharper> smoser: I think looking at that, basic.target is too late
[19:19] <smoser> rharper, its not twice. where do you see that ?
[19:19] <rharper> I mentioned the lines
[19:20] <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:21] <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:22] <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:23] <smoser> which we have to run before
[19:24] <smoser> i think its right.
[19:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:38] <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:46] <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:48] <rharper> smoser: yes
[20:44] <powersj> smoser: ping re: set_hostname vs change_hostname
[20:44] <powersj> err s/change/update/
[20:44] <smoser> powersj, thinking
[20:46] <smoser> ok. so
[20:46] <smoser> update_hostname runs PER_ALWAYS (every boot)
[20:46] <smoser> (more coming)
[21:03] <smoser> powersj, http://pad.ubuntu.com/NtJAvEJEiJ
[21:07] <powersj> smoser: thank you. Let me think about that and implications with testing them
[21:43] <powersj> harlowja: around? question re: cc_ssh_authkey_fingerprints
[22:11] <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:12] <rharper> and sysinit.target is before dbus.service; hence the loop
[22:13] <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:15] <smoser> rharper, fixing
[22:31]  * rharper relocates home
[22:46] <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/
[23:00] <powersj> vans163: I think so... take a look at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resizefs
[23:04] <vans163> powersj: ty guessing default may not be true
[23:54] <smoser> vans163, yes.
[23:54] <smoser> was it not doing that ?
[23:55] <smoser> you can tell it not to. but generally thats the desired behavior