[00:43] 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? === harlowja is now known as harlowja_away === zz_gondoi is now known as gondoi === gondoi is now known as zz_gondoi === harlowja_away is now known as harlowja [17:53] anotheral typically clearing out the cloud-init data folder should do it [17:53] http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html [17:53] if u are making a new AMI i would also do other cleanup to [17:54] cleaning out any other settings (your own ssh keys that were installed...) [18:41] yeah it's very weird - i'm starting with an official ubuntu 12.04 daily AMI [18:41] instantiate it, clear out /var/lib/cloud and ~ubuntu/.ssh/authorized_keys [18:41] and make a new AMI. the authorized_keys file remains empty when I instantiate the new AMI [18:47] hmmm [18:47] seems odd, that shouldn't happen [18:47] do u have the cloud-init log files from when u make a new instance from your new AMI? [18:51] lemme check those [19:20] 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] broskos i thought the heat folks had some callback mechanism? perhaps asking in #heat channel ? [19:42] harlowja: thanks, I'll try. [19:43] 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] ya, i know one way cloud-init can do it, but i thought the heat folks used a different strategy [19:44] 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] that more of signals when cloud-init is done, which could be used to also say 'chef' is done [19:44] saw that thanks. [19:45] can't seem to get it to send the right bits back to heat [19:45] let me know if u find out, i've always wondered how to and never had enough time to investigate [19:45] still poking - I'll come up with somehting... I just mostly wanted to make sure I wasn't overlooking something more obvious [19:46] 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] k [19:46] adds more configurability... [19:53] heh - had to hack in a small portion of that myself. [19:54] current version doesn't run chef-client except on a gem install [19:54] I'll keep an eye on that branch, it's much better than what Ive got going [20:15] :) === zz_gondoi is now known as gondoi [21:07] harlowja: ok - from within heat you create your wait_condition and your wait_handle [21:07] like this guy does here: [21:08] https://developer.rackspace.com/blog/openstack-orchestration-in-depth-part-2-single-instance-deployments/ [21:08] very basic, name them what you will [21:08] k, then heat just polls until that stuff is done? [21:08] the wait_handle when you reference it will return a url that you can post to [21:08] so now you can use phone_home [21:08] ah [21:08] phone_home: url: Ref: "GoServerWaitHandle" post: [ instance_id ] [21:09] you can also daisy chain config blocks and user data together via mulipart mime [21:09] and they will process sequentially, [21:09] so chef config first, then one that does a notfiy back using heat stuff... [21:10] right [21:10] but that is more complicated than what I needed, since I only wanted the chef config to notify [21:10] not many people know about that mime multipart stuff, the heat folks do, ha [21:11] 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] ya :-/ [21:12] in the end I got the multipart mime to work, but then backed it out and when back to phone_home === gondoi is now known as zz_gondoi