=== harlowja is now known as harlowja_away
[11:54] <harmw> smoser: when may we expect a new version of ci to be released? i've got some important fixes in https://code.launchpad.net/~harmw/cloud-init/freebsd that I'd like in before I go for it and upload a real port to the freebsd ports system
[15:05] <smoser> harmw, i dont have a strong plan for a release, but we can get your code merged in.
[15:06] <harmw> ok, well, I'd like a version bump in some form to allow me to build with the merged code :)
[15:07] <harmw> btw, i've submitted the dependencies that aren't currently in freebsd ports earlier today
[15:07] <harmw> 2 packages, but still
=== praneshp_ is now known as praneshp
=== harlowja_away is now known as harlowja
[20:32] <harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/freebsd/+merge/231024
[20:33] <harmw> harlowja: those fbsd initscripts from sean were a bit wacky I'm afraid :p
[20:34] <smoser> harmw, thanks for being awesome.
[20:34] <harlowja> yo yo
[20:35] <harlowja> harmw haha
[20:35] <harlowja> harmw u getting it up into freebsd repos i see, woot
[20:36] <harmw> harlowja: yes, I already did the jsonpatch and jsonpointer ports. Someone from the fbsd project needs to commit them, after that they're live
[20:36] <harlowja> cool
[20:37] <harmw> I'm now working on the cloud-init port, but that a little more complicated
[20:37] <harmw> though thats because of all these new packaging tools I need to learn :p
[20:39] <harlowja> :)
[20:40] <harmw> btw, if either one of you knows someone on the neutron crew
[20:40] <harmw> have them work out https://review.openstack.org/#/c/77471/ :p
[20:40] <harmw> it's abandoned
[20:41] <harmw> which is sad
[20:41] <harlowja> mark killed it, haha
[20:41] <harlowja> i can bug mark about it i guess (he's on my team)
[20:41] <harmw> hehe
[20:42] <harmw> I think it's Randy (who created the code) who needs to fix something now though, but still :p
[20:44] <harlowja> ya, if person doesn't fix the code, not sure what i can do :-P
[20:44] <harlowja> *or keep pushing the review discussion/fixes...
[21:06] <devicenull> Is there a list somewhere of what metadata cloud-init relies on from the ec2 metadata source?
[21:09] <harlowja> devicenull unsure what that means ;)
[21:09] <devicenull> right, that kinda incomprehensible
[21:10] <harlowja> the metadata api is pretty generic that ec2 can expose, cloudinit will just extract all the resources on demand
[21:10] <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/ec2_utils.py#L40 is the code that does this
[21:10] <devicenull> so, what I'm looking for is a list of what metadata cloud-init relies on to actually do things.  I'm writing an implementation of the ec2 metadata service for our software
[21:10] <harlowja> but the initial fetch from ec2 defines what subsequent keys are fetched...
[21:11] <harlowja> so i'd say the key items that it uses are block-device-mapping
[21:11] <harlowja> ssh-keys
[21:11] <harlowja> and userdata (of course)
[21:11] <harlowja> http://docs.aws.amazon.com/AWSEC2/2008-05-05/DeveloperGuide/index.html?AESDG-chapter-instancedata.html
[21:12] <harlowja> availability-zone also (although this is less used)
[21:12] <harlowja> and the hostname ones
[21:12] <devicenull> okay, thanks!
[21:12] <harlowja> 'ami-launch-index' will be used, although its optional
[21:12] <harlowja> and of course instance-id
[21:12] <devicenull> I'm thinking the safest way to go is to provide as many of the values as possible
[21:12] <devicenull> and that are relevant to us
[21:13] <harlowja> yup
[21:13] <harlowja> those i would call the main key ones
[21:13] <harlowja> ssh-keys can be empty
[21:14] <harlowja> i'd make sure yours provides, userdata, instance-id, block-device ones and ssh-keys (although u can return ssh-keys as empty)
[21:14] <devicenull> ok
[21:14] <harlowja> and the hostname ones although cloud-init will skip those if its not there
[21:14] <harlowja> and try to find the hostname by other mechanisms
[21:14] <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L45 is the basic datasource
[21:14] <harlowja> that modules and all that get access to
[21:14] <harlowja> methods there expose some of the above
[21:15] <devicenull> ah, ok that's handy
[21:15] <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L164 (for example has the hostname logic)
[21:16] <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/tools/mock-meta.py might be useful for u too
[21:16] <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/tools/mock-meta.py#L192 (probably this function most useful)
[21:33] <devicenull> ahha
[21:33] <devicenull> yea that last one is very useful
[21:37] <devicenull> so the network/* paths aren't used?
[21:54] <devicenull> btw is there an actual better debug option?  even with --debug, I don't actually get any info on what cloud-init is doing
[21:54] <devicenull> just some internal debug
[22:02] <harlowja> devicenull network/* paths?
[22:24] <devicenull> network/interfaces/macs/mac/device-number
[22:24] <devicenull> from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html
[22:33] <harlowja> hmmm devicenull that seems newer than what cloudinit knows about
[22:34] <harlowja> at least i didn't know that existed
[22:34] <harlowja> devicenull anyway, cloud-init will read that, but it doesn't appear used yet afaik
[22:35] <harlowja> devicenull as for debug, u should be able to get debug logs in /var/log/cloud-init.log
[22:35] <harlowja> can also adjust the logging levels to do this to
[22:35] <harlowja> when starting an instance
[22:35] <harlowja> depending on what cloud-init version u have this is easier/harder