[11:15] <mhroncok> hi again
[11:15] <mhroncok> any chance of this being merged? https://code.launchpad.net/~harlowja/cloud-init/py2-3
[16:22] <tennis> smoser: U there? 
[16:24] <smoser> here.
[16:24] <smoser> you dropped yesterday.
[16:25] <smoser> files are loaded and merged with later getting preference over newer
[16:25] <tennis> smoser: Yup.  Sorry.  Life got in the way.  Thanks for responding. 
[16:25] <smoser> /etc/cloud/cloud.cfg , then /etc/cloud/cloud.cfg.d/*.cfg in C locale sorted order
[16:27] <tennis> 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] <tennis> 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] <smoser> tennis, cloud-init does that.
[17:06] <smoser> tennis, it should do that.
[17:07] <tennis> 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] <smoser> tennis, i'd 'backdoor' the images, giving you another way in
[17:12] <tennis> smoser: ...and the best way to do that is ... ? (sorry,  yet another question :))
[17:16] <smoser> tennis, ubuntu ?
[17:16] <smoser> what i would use to backdoor an image is
[17:16] <smoser> https://code.launchpad.net/~smoser/+junk/backdoor-image
[17:18] <tennis> smoser: Ah, so its "baked in" to the image. 
[17:19] <smoser> right.
[17:19] <smoser> thats how i debug such things
[17:21] <tennis> smoser: Thanks
[17:21] <tennis> smoser: I'll use packer to drive the image setup with 'backdoor' included.  That should enable everything.
[17:33] <tennis> smoser:  Not sure how backdoor-image would be called.  Is the 'target' meant to be an AMI? 
[17:37] <tennis> smoser: basically, i'm wondering where it is called from and what the target should be.
[18:15] <smoser> tennis, sorry. target is some disk image.
[18:15] <smoser> or root filesystem.
[19:30] <tennis> smoser: got it. 
[19:31] <tennis> smoser: makes it complicated to use with an aws ami. Hmmm ... 
[19:37] <smoser> well what would you want it to take ?
[20:19] <tennis> 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] <smoser> it will work on active filesystem, yes.
[20:20] <smoser> block device or filesystem root
[20:20] <smoser> ie, backdoor-image /
[20:20] <smoser> or
[20:20] <smoser> backdoor-image /dev/sda
[20:20] <smoser> or 
[20:20] <tennis> smoser: ah,ok  ...Thanks
[20:20] <smoser> backdoor-image my.qcow2
[20:21] <smoser> fwiw, its logic is just:
[20:21] <smoser>  if -d $PATH; then
[20:21] <smoser>    operate on path
[20:22] <smoser>  elif -b $PATH; then
[20:22] <smoser>    call mount-image-callback $0 _MOUNTPOINT_ "$@"
[20:22] <tennis> 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] <tennis> smoser: ok. That makes sense.
[20:23] <smoser> well, if you're feeding bad yaml
[20:23] <smoser> then just:
[20:23] <smoser>  python -c 'import yaml; yaml.load(open("my.yaml").read())'
[20:23] <smoser> will likely give the same error
[20:23] <tennis> perfect.  Thansk
[20:23] <tennis> thanks
[20:25] <tennis> Yup.  That found it.
[21:36] <dryicerx> hello. Is there a accepted method for enabling services (upstart specific) via cloud init in a clean manner
[21:36] <dryicerx> (or enabling/disabling services with a clean cloudinit way)
[22:35] <tennis> smoser: How to debug "failed to shellify" errors?