=== harlowja is now known as harlowja_away === praneshp_ is now known as praneshp [06:37] Can I bake some user-data into an image (EC2 AMI) such that I don't have to pass instances user-data when i instantiate them? I.E. does cloud-init also look for configuration on the local machine? If so, where? [06:38] I'm trying to take as much of the edge off of instantiating images for the rest of my team, and I really only need to take care of a small, unchanging set of cloud-init tasks === evilissimo|afk is now known as evilissimo === alexpilotti_ is now known as alexpilotti [15:27] Hi, I experimented a strange bug today with cloud init [15:28] Stdin is redirected to /var/log/cloud-init-output.log via tee [15:28] When using SaltStack salt [15:29] and after a few minutes configuring my machines (AWS Ubuntu 14.04) [15:29] all the processes stop working [15:29] except for "tee" [15:29] which keeps running at 100% [15:30] for 10 long minutes [15:30] and then everything goes normal again [15:34] When I disable the redirection via tee to /var/log/cloud-init-output.log [15:34] It works ok. === evilissimo is now known as evilissimo|afk [16:10] smoser: Hi! Sorry I had been sidetracked on adding a "grow" feature to mount-image-callback [16:10] guilload, hm.. [16:11] smoser: I've added it (well I've mainly added support to growpart and reuse growpart and resize-part-image from mount-image-callback, but I'm having some issues running chrooted commands using mount-image-callback [16:11] guilload, i've never seen that. but it doesn't seem impossible. [16:14] I've just fixed my problem by redirecting stdout and stderr to /dev/null [16:14] i'm adding metadata (not userdata) to an openstack instance that i've created using a config-drive. does cloud-init save this metadata somewhere? all i can find is a pickle file [16:15] smoser: I'm just not sure how to run commands, if I follow the example: /mount-image-callback -v trusty-server-cloudimg-amd64-disk1.img -- chroot _MOUNTPOINT_ /bin/sh [16:15] and add /mount-image-callback -v trusty-server-cloudimg-amd64-disk1.img -- chroot _MOUNTPOINT_ /bin/sh -c "ls /" [16:15] it won't work (it'll complain about "-c") [16:15] but I've taken a look at how the redirection is done to tee and it does look a little clumsy [16:15] any idea on how to properly issue the chrooted command? [16:23] agy, no. [16:24] i dont think so. maybe in the pickle. [16:24] but not in a good format. [16:24] smoser: ok, that's what i thought. thanks [16:24] the goal is to have have that sort of stuff in /run somewhere [16:24] it's in the pickle fwiw [16:25] that's where i expected it to be ;-) [16:25] the goal is to put a /run/instance-data.json and /run/instance-data-private.json [16:25] with the -private having things are known priviledged info [16:25] that would be ideal [16:25] patches are welcome. [16:26] in fact, you canprobably just ask harlowja_away to do it for you [16:26] :) [16:26] * agy was waiting for that [16:26] ^^ the "patches" comment [16:26] guilload, how clumsy ? [16:27] it might be, but its been used that way for quite a while. the default did change in 14.04 to redirect. but prior to that i always used that output definition and so did many other usres. [16:27] i'm intereted in fixing it. can you file a bug with a reproducible example ? [16:27] yes [16:28] First, I will try to reproduce the bug :) [16:28] CatKiller, hm.. example of chrooted commands issues ? [16:29] CatKiller, hm.. it should be fine like that. [16:29] you do need that '--' but mount-image-callback should respect it. [16:30] smoser: Ah I wasn't sure I needed it [16:30] smoser: In fact I think it's my bad, I have a 64bit image and I'm on a 32bit system.... [16:31] smoser: I should be OK once I get the 32bit one :p [16:39] wow. you have a 32 bit system ? [16:40] is your atari 2600 sitting on top of it ? [16:56] smoser: Well in fact it's a 64bit machine I think, but it's one of the first AMD ever produced so it behaves better in 32bit ;) [16:57] smoser: But yes the hardware we have at work here is laughable. I recently got an upgrade to 2GB of RAM from 512M [16:57] :p [16:58] * smoser sends CatKiller 512M dimm [16:58] I'll have to refuse them: all my DIMM slots are now full! :P [16:59] My phone is more powerful than my dev machine now... [16:59] actually not quite, I haven't upgraded to an iPhone 5 but if I did it would! [17:06] smoser: Would there be an easy way to pass the contents of a script to the chroot command instead of relying on running /bin/sh in mount-image-callback? === harlowja_away is now known as harlowja [17:21] smoser whats this, what code, lol [17:21] do waht, lol [17:22] i volunteer SpamapS to do whatever it is, ha [18:21] harlowja: challenge accepted. First step: rewrite it in go. [18:21] lol [18:21] damn it [18:22] SpamapS https://github.com/coreos/coreos-cloudinit u already did that, lol [18:22] smoser have u seen ^ ;) [18:22] looks similar right (but in go, haha) [18:23] except its to much hipster for me [18:23] lol [18:24] yeah, i saw that a while ago. [18:24] i'm having fun with that same thing right now [18:24] that same thing being "doing the same thing only different" [18:25] as i try to get cloud-init and systemd working on ubuntu [18:25] horray for useful exercises in time [18:25] [18:28] :) [19:38] smoser are u just trying to convert the upstart stuff to systemd or is it more extensive than that? [19:39] well.. [19:39] https://code.launchpad.net/~smoser/cloud-init/systemd-enable/ [19:40] but in order to get to systemd functional, i had to do some other things... and then xnox helped and clean up some of hte packaging [19:40] so its kind of snowballed. [19:42] :-/ [19:43] fun fun [19:46] harlowja, https://code.launchpad.net/~xnox/cloud-init/fix-systemd-install-paths/+merge/227918 [19:46] do you know why those were put in /etc ? [19:47] no idea [19:47] * harlowja i haven't done much with systemd first [19:47] waiting till u figure it all out ;) [19:47] well, it blames to you [19:48] hmmm [19:48] odd [19:48] lol [19:48] and your fix-everything-smoser-did branch [19:48] oh well. [19:48] hmmm, lies [19:48] haha [19:48] fix-everything-smoser-did branch, haha [19:49] probably i didn't do it right, blame accepted