[00:43] <anotheral> question: what do I need to do to get cloud-init to reload the ubuntu user's authorized keys from AWS metadata, when i'm creating a new AMI?
[17:53] <harlowja> anotheral typically clearing out the cloud-init data folder should do it
[17:53] <harlowja> http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html 
[17:53] <harlowja> if u are making a new AMI i would also do other cleanup to
[17:54] <harlowja> cleaning out any other settings (your own ssh keys that were installed...)
[18:41] <anotheral> yeah it's very weird - i'm starting with an official ubuntu 12.04 daily AMI
[18:41] <anotheral> instantiate it, clear out /var/lib/cloud and ~ubuntu/.ssh/authorized_keys
[18:41] <anotheral> and make a new AMI.  the authorized_keys file remains empty when I instantiate the new AMI
[18:47] <harlowja> hmmm
[18:47] <harlowja> seems odd, that shouldn't happen
[18:47] <harlowja> do u have the cloud-init log files from when u make a new instance from your new AMI?
[18:51] <anotheral> lemme check those
[19:20] <broskos> I'm using cloud-init with a chef block to install and run chef. How can I notify cfn or heat when the chef run has completed?  Is there a way to do this with cloud-init?
[19:35] <harlowja> broskos i thought the heat folks had some callback mechanism? perhaps asking in #heat channel ?
[19:42] <broskos> harlowja: thanks, I'll try.  
[19:43] <broskos> I see their waithandles and such, and cfn-signal which is pretty straight forward.  Just working on sorting out how to tell when the chef run is finished at the moment
[19:44] <harlowja> ya, i know one way cloud-init can do it, but i thought the heat folks used a different strategy
[19:44] <harlowja> aka, http://cloudinit.readthedocs.org/en/latest/topics/examples.html#call-a-url-when-finished is one way, but i didn't think this was the way
[19:44] <harlowja> that more of signals when cloud-init is done, which could be used to also say 'chef' is done
[19:44] <broskos> saw that thanks.
[19:45] <broskos> can't seem to get it to send the right bits back to heat
[19:45] <harlowja> let me know if u find out, i've always wondered how to and never had enough time to investigate
[19:45] <broskos> still poking - I'll come up with somehting... I just mostly wanted to make sure I wasn't overlooking something more obvious
[19:46] <harlowja> broskos u might be interested in https://code.launchpad.net/~harlowja/cloud-init/better-chef-module/+merge/238040 which yahoo is using (until that merges)
[19:46] <broskos> k
[19:46] <harlowja> adds more configurability...
[19:53] <broskos> heh - had to hack in a small portion of that myself.
[19:54] <broskos> current version doesn't run chef-client except on a gem install
[19:54] <broskos> I'll keep an eye on that branch, it's much better than what Ive got going
[20:15] <harlowja> :)
[21:07] <broskos> harlowja: ok - from within heat you create your wait_condition and your wait_handle
[21:07] <broskos> like this guy does here:
[21:08] <broskos> https://developer.rackspace.com/blog/openstack-orchestration-in-depth-part-2-single-instance-deployments/
[21:08] <broskos> very basic, name them what you will
[21:08] <harlowja> k, then heat just polls until that stuff is done?
[21:08] <broskos> the wait_handle when you reference it will return a url that you can post to
[21:08] <broskos> so now you can use phone_home
[21:08] <harlowja> ah
[21:08] <broskos>           phone_home:             url:               Ref:  "GoServerWaitHandle"             post: [ instance_id ]
[21:09] <broskos> you can also daisy chain config blocks and user data together via mulipart mime
[21:09] <broskos> and they will process sequentially, 
[21:09] <broskos> so chef config first, then one that does a notfiy back using heat stuff...
[21:10] <harlowja> right
[21:10] <broskos> but that is more complicated than what I needed, since I only wanted the chef config to notify
[21:10] <harlowja> not many people know about that mime multipart stuff, the heat folks do, ha
[21:11] <broskos> I found it confusing, mostly because there are 3 different template formats and various posts will have used a format slightly different that what you are using causing a lot of time interpreting and converting
[21:11] <harlowja> ya :-/
[21:12] <broskos> in the end I got the multipart mime to work, but then backed it out and when back to phone_home