=== harlowja_ is now known as harlowja_away [11:15] hi again [11:15] any chance of this being merged? https://code.launchpad.net/~harlowja/cloud-init/py2-3 [16:22] smoser: U there? [16:24] here. [16:24] you dropped yesterday. [16:25] files are loaded and merged with later getting preference over newer [16:25] smoser: Yup. Sorry. Life got in the way. Thanks for responding. [16:25] /etc/cloud/cloud.cfg , then /etc/cloud/cloud.cfg.d/*.cfg in C locale sorted order [16:27] smoser: ok. Do I need to explicitly call "curl http://169.254.169.254(etc)" to get my public keys, or is that accomplished somewhere automatically in cloud-init processing? [16:30] smoser: I already have a key pair defined in my environment, but for some reason the init process doesn't put it into the "~/.ssh/authorized_keys" file. Trying to figure out where it comes from. [17:06] tennis, cloud-init does that. [17:06] tennis, it should do that. [17:07] smoser: Thats what I was thinking too. But for some reason it does not seem to. Can't get into my images because of it. Can you point me to a minimalist example that should do that and notthing (or very little) more? [17:11] tennis, i'd 'backdoor' the images, giving you another way in [17:12] smoser: ...and the best way to do that is ... ? (sorry, yet another question :)) [17:16] tennis, ubuntu ? [17:16] what i would use to backdoor an image is [17:16] https://code.launchpad.net/~smoser/+junk/backdoor-image [17:18] smoser: Ah, so its "baked in" to the image. [17:19] right. [17:19] thats how i debug such things [17:21] smoser: Thanks [17:21] smoser: I'll use packer to drive the image setup with 'backdoor' included. That should enable everything. [17:33] smoser: Not sure how backdoor-image would be called. Is the 'target' meant to be an AMI? [17:37] smoser: basically, i'm wondering where it is called from and what the target should be. === harlowja_away is now known as harlowja_ [18:15] tennis, sorry. target is some disk image. [18:15] or root filesystem. [19:30] smoser: got it. [19:31] smoser: makes it complicated to use with an aws ami. Hmmm ... [19:37] well what would you want it to take ? [20:19] smoser: Just saw your resp. Can it be used on an active filesystem, or does it expect it to be an externally-mounted drive? [20:20] it will work on active filesystem, yes. [20:20] block device or filesystem root [20:20] ie, backdoor-image / [20:20] or [20:20] backdoor-image /dev/sda [20:20] or [20:20] smoser: ah,ok ...Thanks [20:20] backdoor-image my.qcow2 [20:21] fwiw, its logic is just: [20:21] if -d $PATH; then [20:21] operate on path [20:22] elif -b $PATH; then [20:22] call mount-image-callback $0 _MOUNTPOINT_ "$@" [20:22] smoser: I noticed you wrote util.py in cloud-init (nicely done, btw). I'm getting "util.py[WARNING]: Failed loading yaml blob" errors. How do I make the output verbose enough to tell me where the problem is? Or, is there a way to validate the yaml with your code offline? [20:22] smoser: ok. That makes sense. [20:23] well, if you're feeding bad yaml [20:23] then just: [20:23] python -c 'import yaml; yaml.load(open("my.yaml").read())' [20:23] will likely give the same error [20:23] perfect. Thansk [20:23] thanks [20:25] Yup. That found it. [21:36] hello. Is there a accepted method for enabling services (upstart specific) via cloud init in a clean manner [21:36] (or enabling/disabling services with a clean cloudinit way) [22:35] smoser: How to debug "failed to shellify" errors? === shardy is now known as shardy_z