[06:37] <KaaK> 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] <KaaK> 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
[15:27] <guilload> Hi, I experimented a strange bug today with cloud init
[15:28] <guilload> Stdin is redirected to /var/log/cloud-init-output.log via tee
[15:28] <guilload> When using SaltStack salt
[15:29] <guilload> and after a few minutes configuring my machines (AWS Ubuntu 14.04)
[15:29] <guilload> all the processes stop working
[15:29] <guilload> except for "tee"
[15:29] <guilload> which keeps running at 100%
[15:30] <guilload> for 10 long minutes
[15:30] <guilload> and then everything goes normal again
[15:34] <guilload> When I disable the redirection via tee to /var/log/cloud-init-output.log
[15:34] <guilload> It works ok.
[16:10] <CatKiller> smoser: Hi! Sorry I had been sidetracked on adding a "grow" feature to mount-image-callback
[16:10] <smoser> guilload, hm..
[16:11] <CatKiller> 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] <smoser> guilload, i've never seen that. but it doesn't seem impossible.
[16:14] <guilload> I've just fixed my problem by redirecting stdout and stderr to /dev/null
[16:14] <agy> 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] <CatKiller> 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] <CatKiller> and add /mount-image-callback -v trusty-server-cloudimg-amd64-disk1.img -- chroot _MOUNTPOINT_ /bin/sh -c "ls /"
[16:15] <CatKiller> it won't work (it'll complain about "-c")
[16:15] <guilload> but I've taken a look at how the redirection is done to tee and it does look a little clumsy
[16:15] <CatKiller> any idea on how to properly issue the chrooted command?
[16:23] <smoser> agy, no. 
[16:24] <smoser> i dont think so. maybe in the pickle.
[16:24] <smoser> but not in a good format.
[16:24] <agy> smoser: ok, that's what i thought. thanks
[16:24] <smoser> the goal is to have have that sort of stuff in /run somewhere
[16:24] <agy> it's in the pickle fwiw
[16:25] <agy> that's where i expected it to be ;-)
[16:25] <smoser> the goal is to put a /run/instance-data.json and /run/instance-data-private.json
[16:25] <smoser> with the -private having things are known priviledged info
[16:25] <agy> that would be ideal
[16:25] <smoser> patches are welcome.
[16:26] <smoser> in fact, you canprobably just ask harlowja_away to do it for you
[16:26] <smoser> :)
[16:26]  * agy was waiting for that
[16:26] <agy> ^^ the "patches" comment
[16:26] <smoser> guilload, how clumsy ?
[16:27] <smoser> 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] <smoser> i'm intereted in fixing it. can you file a bug with a reproducible example ?
[16:27] <guilload> yes
[16:28] <guilload> First, I will try to reproduce the bug :)
[16:28] <smoser> CatKiller, hm.. example of chrooted commands issues ?
[16:29] <smoser> CatKiller, hm.. it should be fine like that.
[16:29] <smoser> you do need that '--' but mount-image-callback should respect it.
[16:30] <CatKiller> smoser: Ah I wasn't sure I needed it
[16:30] <CatKiller> smoser: In fact I think it's my bad, I have a 64bit image and I'm on a 32bit system....
[16:31] <CatKiller> smoser: I should be OK once I get the 32bit one :p
[16:39] <smoser> wow. you have a 32 bit system ?
[16:40] <smoser> is your atari 2600 sitting on top of it ?
[16:56] <CatKiller> 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] <CatKiller> 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] <CatKiller> :p
[16:58]  * smoser sends CatKiller 512M dimm 
[16:58] <CatKiller> I'll have to refuse them: all my DIMM slots are now full! :P
[16:59] <CatKiller> My phone is more powerful than my dev machine now...
[16:59] <CatKiller> actually not quite, I haven't upgraded to an iPhone 5 but if I did it would!
[17:06] <CatKiller> 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?
[17:21] <harlowja> smoser whats this, what code, lol
[17:21] <harlowja> do waht, lol
[17:22] <harlowja> i volunteer SpamapS  to do whatever it is, ha
[18:21] <SpamapS> harlowja: challenge accepted. First step: rewrite it in go.
[18:21] <harlowja> lol
[18:21] <harlowja> damn it
[18:22] <harlowja> SpamapS https://github.com/coreos/coreos-cloudinit u already did that, lol
[18:22] <harlowja> smoser have u seen ^ ;)
[18:22] <harlowja> looks similar right (but in go, haha)
[18:23] <harlowja> except its to much hipster for me
[18:23] <harlowja> lol
[18:24] <smoser> yeah, i saw that a while ago.
[18:24] <smoser> i'm having fun with that same thing right now
[18:24] <smoser> that same thing being "doing the same thing only different"
[18:25] <smoser> as i try to get cloud-init and systemd working on ubuntu
[18:25] <smoser> horray for useful exercises in time

[18:28] <harlowja> :)
[19:38] <harlowja> smoser are u just trying to convert the upstart stuff to systemd or is it more extensive than that?
[19:39] <smoser> well..
[19:39] <smoser>  https://code.launchpad.net/~smoser/cloud-init/systemd-enable/
[19:40] <smoser> 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] <smoser> so its kind of snowballed.
[19:42] <harlowja> :-/
[19:43] <harlowja> fun fun
[19:46] <smoser> harlowja, https://code.launchpad.net/~xnox/cloud-init/fix-systemd-install-paths/+merge/227918
[19:46] <smoser> do you know why those were put in /etc ?
[19:47] <harlowja> no idea
[19:47]  * harlowja i haven't done much with systemd first 
[19:47] <harlowja> waiting till u figure it all out ;)
[19:47] <smoser> well, it blames to you
[19:48] <harlowja> hmmm
[19:48] <harlowja> odd
[19:48] <harlowja> lol
[19:48] <smoser> and your fix-everything-smoser-did branch
[19:48] <smoser> oh well.
[19:48] <harlowja> hmmm, lies
[19:48] <harlowja> haha
[19:48] <harlowja> fix-everything-smoser-did branch, haha
[19:49] <harlowja> probably i didn't do it right, blame accepted